FMX-Styles : StyleLookup zu Controls zuordnen?

[himitsu]

Tachchen,

der Property-Editor im OI listet ja im Property StyleLookup oft so Einiges auf,
aber woher weiß er was er da auflisten muß?

z.B. was ganz Einfaches: TSizeGrip hat nur einen Style
aber wenn ich jetzt z.B. einen TButton nehmen, dann gibt es da viele Styles, nur diesen Einen natürlich nicht.

Gut, ich kann manuell sizegripstyle dort eintragen und schon sieht der TButton wie ein TSizeGrip aus.


Allerdings finde ich nirgendwo etwas, was mir programmseitig sagt "jo, für TButton gibt es diese Styles"
oder "also dieser Style" gehört zu dieser Komponente diesen Komponenten.

z.B. der Style cleareditbutton gehört zum TButton, aber auch zum TClearEditButton,
während beim TClearEditButton nur dieses cleareditbutton gelistet wird, hat der TButton sehr sehr zuviel andere Styles.


Also weder im SourceCode steht igendwo etwas (kein "sizegripstyle" zu finden ... hätte fast vermutet die Komponenten "wissen" es jeweils selbst)
noch im Style selbst kann ich etwas dafür finden.


https://geheimniswelten.de/GitHub/FM...iew_v2test.exe (Source auf GitHub, als Branch versteckt)

[milos]

Hi,

wo genau es definiert ist kann ich dir nicht sagen, aber der OI wird alle Styles auflisten welche die Komponente im StyleNamen haben. Deswegen wird cleareditbutton auch bei TButton aufgelistet.

Dass das wirklich so "doof" ist kannst du ganz einfach testen indem du ein custom style für ein Label erstellst und es my_button_style nennst oder wie auch immer, das wird dann bei Buttons aufgelistet aber nicht bei Labels.

Freundliche Grüsse

[himitsu]

Bei vielen Komponenten stimmt es schon, aber ganz so einfach kann es doch nicht sein.
> T weglassen und nach dem Namen suchen

TSpeedButton oder TColorListBox stehen nicht in ihren Styles

TScrollBar und TSmallScrollBar stehen in ihren Styles, aber bei denen werden sie garnicht aufglistet, obwohl es mehrere Styles dafür gibt.

Oder beim TListBoxGroupHeader wird nur der listboxplainheader gefunden,
aber beim TListBoxItem passt es aber wieder, also mehreres mit listboxitem.

Dagegen, bei der TTreeView wird auch der treeviewitemstyle vom TTreeViewItem mit gelistet



Und für eine Rückwärtssuche wäre sowas auch extrem ungünstig.
Ich kann zwar einen Style für die Vorschau direkt anzeigen, aber in einer Komponente sieht es oft schon anders aus, weil da dann Teile umarrangiert werden.

[milos]

Zitat von himitsu:

Bei vielen Komponenten stimmt es schon, aber ganz so einfach kann es doch nicht sein.
> T weglassen und nach dem Namen suchen

TSpeedButton oder TColorListBox stehen nicht in ihren Styles

TScrollBar und TSmallScrollBar stehen in ihren Styles, aber bei denen werden sie garnicht aufglistet, obwohl es mehrere Styles dafür gibt.

Oder beim TListBoxGroupHeader wird nur der listboxplainheader gefunden,
aber beim TListBoxItem passt es aber wieder, also mehreres mit listboxitem.

Dagegen, bei der TTreeView wird auch der treeviewitemstyle vom TTreeViewItem mit gelistet



Und für eine Rückwärtssuche wäre sowas auch extrem ungünstig.
Ich kann zwar einen Style für die Vorschau direkt anzeigen, aber in einer Komponente sieht es oft schon anders aus, weil da dann Teile umarrangiert werden.

Okay das mit dem TreeViewItems ist ja mal zu lustig, hatte auch schon komisches gesehen aber das noch nicht.

Ich hab interessenshalber mal nachgeschaut, weil ich das verhalten bei ListBoxItem so auch nicht kannte bzw es nicht realisiert habe.

In FMX.Controls in TStyledControl wird eine public const string definiert:

Delphi-Quellcode:

  TStyledControl = class(TControl)
  public const
    StyleSuffix = 'style';
  ...

Dann gibts in der selben Unit/Klasse noch diese drei Funktionen:
(aus lizenztechnischen Gründen nur die Header, sollte es erlaubt sein Code für solche zwecke zu zeigen, lasst es mich wissen)

Delphi-Quellcode:

function TStyledControl.GenerateStyleName(const AClassName: string): string; // 6 Zeilen Code

Die macht eigentlich nichts anderes als:
- Result = AClassName.
- Wenn Result mit TCustom beginnt, wird es weggeschnitten.
- Wenn Result mit T beginnt, wird es weggeschnitten.
- Result + StyleSuffix (style) wird zurückgegeben (Ja, die Funktion hat einen Bug wenn das Control mit TCustomT beginnt )

Hier kommt also das "buttonstyle", "labelstyle" usw her...

Es gibt dann noch diese zwei ein-zeiler/helper funktionen:

Delphi-Quellcode:

function TStyledControl.GetDefaultStyleLookupName: string; // Eine Zeile
function TStyledControl.GetParentClassStyleLookupName: string; // Eine Zeile

Ich nehme mal an bei ListBox haben Sie noch das Root Component geprüft und bei TreeView gar nichts. Man könnte jetzt weiter gehen und schauen wie genau Embarcadero das macht, aber wahrscheinlich findest du ne bessere Alternative.

Code:

PS ...\embarcadero\studio\23.0\source\fmx> Select-String -Path "./*.pas" -Pattern "GetParentClassStyleLookupName"

Findet bei mir 14 weitere Ergebnisse...

Edit: Hab bisschen weiter gestöbert und ich denke hier ist es definiert:

(\embarcadero\studio\23.0\source\Property Editors\FmxStyleLookup.pas)

• In der Funktion TStyleLookupPropertyValues.GetValues(Proc: TGetStrProc)...

• Hat noch eine sub-routine AddStylesForControl(const StyleObject: TFmxObject);

• In der Hauptroutine GetValues wird als erstes TStyleLookupPropertyValues.GetStyledControl aufgerufen.
• In GetStyledControl wird der DefaultStyleLookupName (von FMX.Controls.TStyledControl, siehe oben) benutzt um den default stylenamen zu kriegen. (z.b. buttonstyle)
• Das "style" wird wieder entfernt. (also zurück zu button)
• Es wird durch die styles gelooped und die matches werden als properties aufgelistet.

• Ein paar Komponenten werden geskippt (definiert als hardcoded strings in der selben Datei)

Bin gerade zu müde den Code zu extrahieren / selbst auszuführen / zu debuggen, aber das sollte es sein.

Edit: Formatierung

[himitsu]

Hatte vorgestern angefangen nach dem einen Sonderfall zu suchen und hab ihn sogar gefunden (grade gesehen dass er gefunden wurde)

Delphi-Quellcode:

  TListBoxItem = class(TTextControl, IGlyph)
    function GetDefaultStyleLookupName: string; override;
    function DoGetDefaultStyleLookupName(const Defaults: TListBoxItemStyleDefaults): string; virtual;


function TListBoxSeparatorItem.GetDefaultGroupHeaderStyle: string;
begin
  if ListBox <> nil then
    case ListBox.GroupingKind of
      TListGroupingKind.Plain:
        Result := 'listboxplainheader';  // do not localize
      TListGroupingKind.Grouped:
        Result := 'listboxgroupheader';  // do not localize
    end;
end;

[Harry Stahl]

Da ja solche Fragen "Woher weiß eine FMX-Komponente in welchem Style sie sich zu zeichnen hat?" immer wieder mal auftauchen, in der Anlage ein kleiner Beitrag zur Klärung dieser Frage (4-Seitige PDF). Der Text wurde zum Zeitpunkt von Delphi 10.2 erstellt, aber allzuviel dürfte sich da nicht geändert haben.

Evtl. hilft es ja beim Verständnis, wie man bei eigenen Komponenten den Style entsprechend setzt.

[milos]

Zitat von himitsu:

Hatte vorgestern angefangen nach dem einen Sonderfall zu suchen und hab ihn sogar gefunden (grade gesehen dass er gefunden wurde)

Delphi-Quellcode:

  TListBoxItem = class(TTextControl, IGlyph)
    function GetDefaultStyleLookupName: string; override;
    function DoGetDefaultStyleLookupName(const Defaults: TListBoxItemStyleDefaults): string; virtual;


function TListBoxSeparatorItem.GetDefaultGroupHeaderStyle: string;
begin
  if ListBox <> nil then
    case ListBox.GroupingKind of
      TListGroupingKind.Plain:
        Result := 'listboxplainheader';  // do not localize
      TListGroupingKind.Grouped:
        Result := 'listboxgroupheader';  // do not localize
    end;
end;

Ach da kommt mir in den Sinn, ich habe diese "do not localize" Kommentare gestern noch öfters beim durchstöbern neben hardgecodedeten Komponentennamen gesehen... Ich war aber so Müde, ich dachte das würde sowas heissen wie "nicht in andere Sprache übersetzen" heissen...

Naja, wenn du mit grep o.ä. die FMX lib mit dem Kommentar durchsuchst scheinen noch mehr solcher Fälle vorzukommen... Weiss jetzt nicht genau was du vorhast und wie weit du die Styles <-> Komponentenzuweisung automatisieren willst. Du siehst selbst, Emba macht das alle von Hand und scheint selbst Probleme damit zu haben Ihre Komponenten in Ihrem System richtig zu konfigurieren und aktuell zu halten

Da im TStyleBook export auch nicht mehr als der "StyleName" bei Custom Styles steht hat die IDE auch nicht einfach so genaues Wissen darüber welche custom style nun wirklich für welche Komponenten gedacht sind. Mein Vorschlag wäre eigentlich gewesen semantisch in den Style Controls im TStyleBook zu suchen welche Komponente "so genau wie mölich" zur Definition bzw Regeln der Komponente passen und Sie dort anzeigt, ist auch nicht wirklich brauchbar, denn du könntest ja ein Button auch einfach nur mit einer 'text' Komponente definieren, da weiss man schon wieder nicht genau/automatisch in welche Komponente es wirklich reingehört (button oder label oder einer der ganz vielen anderen bestimmmt...)

Also wenn man dann in die einzelnen Controls z.B. ein Button rein geht und schaut dass selbst die relevanten/interaktiven StyleName's alle hardgecoded (z.B. 'text' für Button oder Label) sind und es nicht irgendwo eine zentrale Stelle gibt bei der diese registriert und mit dem Klassentyp verknüft werden oder sonst irgendetwas... Versteh ich warum es in der IDE nicht so macht wie es sollte: Da fehlt ganz einfach die richtige Struktur und Organisation dafür...

[himitsu]

In meinem Fall hätte ich da grade eine kleine App, welche eine Vorschau der Styles hat,
und da würde ich gern, optional zu einem Style diesen Style in seiner natürlichen Umgebung anzeigen,
also innerhalb der entsprechenden Komponente.

Den "Style" direkt anzuzeigen, so als wäre er selbst die Komponente geht oft, aber in real sieht es dann doch öfters etwas bis ganz anders aus.

https://geheimniswelten.de/GitHub/FMXStyleOverview.png
https://geheimniswelten.de/GitHub/FM...iew_v2test.exe
https://github.com/geheimniswelten/F...rview/tree/2.0


Idee: Mal sehn wie es läuft, wenn ich bei Programmstart via RTTI alle Klassen/Komponenten in der EXE nach FMX-Komponenten durchsuche und Diese dann jeweils frage, welches ihre Styles sind, bzw. was ihr Standardstyle wäre.

Dann könnte ich auch automatisiert auflisten/markieren, welcher dort dann wo etwas fehlt.

[himitsu]

Zitat von milos:

Ach da kommt mir in den Sinn, ich habe diese "do not localize" Kommentare gestern noch öfters beim durchstöbern neben hardgecodedeten Komponentennamen gesehen... Ich war aber so Müde, ich dachte das würde sowas heissen wie "nicht in andere Sprache übersetzen" heissen...

Das bedeutet es im Prinzip auch.
Ist wohl eine Markierung für deren Übersetzungstool, dass diese Strings nicht angefasst werden sollen.

Es sind ja praktisch Eigennamen/IDs.

[milos]

Zitat von himitsu:

In meinem Fall hätte ich da grade eine kleine App, welche eine Vorschau der Styles hat,
und da würde ich gern, optional zu einem Style diesen Style in seiner natürlichen Umgebung anzeigen,
also innerhalb der entsprechenden Komponente.

Den "Style" direkt anzuzeigen, so als wäre er selbst die Komponente geht oft, aber in real sieht es dann doch öfters etwas bis ganz anders aus.

Ah alles klar, sowas in der Richtung wollte ich auch schon machen. Meine Idee war damals eben die TStyleBook Komponenten rekursiv zu durchsuchen und mit den "Vorgaben" des zu stylenden Controls zu vergleichen, aber das scheint wohl nicht wirklich möglich zu sein, ausser du gehst stumpf in jede Komponente und kopierst deren Style Element Namen.

Noch schlimmer ist es mit Custom Controls von Drittanbietern...

Zitat von himitsu:

Idee: Mal sehn wie es läuft, wenn ich bei Programmstart via RTTI alle Klassen/Komponenten in der EXE nach FMX-Komponenten durchsuche und Diese dann jeweils frage, welches ihre Styles sind, bzw. was ihr Standardstyle wäre.

Dann könnte ich auch automatisiert auflisten/markieren, welcher dort dann wo etwas fehlt.

Da findest du ja aber auch nicht alles, oder habe ich dich falsch verstanden? Wenn du z.B. Styles für TLabel hast die "TitleSuccess" und "TitleError" heissen (also ohne die Hilfe von "Label" im Namen), diese aber nirgends beim Programmstart so definiert sind, werden diese ja nicht zugeordnet/gefunden?

Zitat von himitsu:

https://geheimniswelten.de/GitHub/FMXStyleOverview.png
https://geheimniswelten.de/GitHub/FM...iew_v2test.exe
https://github.com/geheimniswelten/F...rview/tree/2.0

Nettes Tool!

Die exe crasht leider (ohne Fehlermeldung oder Eintrag im Event-Viewer ) aber hab's mal selbst kompilliert und ein paar Teststyles reingeladen. Man sieht sofort welche man noch nicht erstellt hat. (oder ich noch erstellen sollte )

Wäre definitiv nützlich wenn man auch die custom styles testen könnte, aber ich glaub ehrlich gesagt das automatische zuordnen ist aktuell nicht so toll umsetzbar (technisch gesehen), bis auf den standard style "componentstyle" und so wies Emba macht, einfach stumpf alles mit "component" im stylenamen aufzulisten. Ich mache das sowieso eigentlich immer so das ich den custom styles den Namen der Komponente mitgebe, also für mich klappt das eigentlich.