FMX-Styles : StyleLookup zu Controls zuordnen?

[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.