FMX-Styles : StyleLookup zu Controls zuordnen?

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

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

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