[FMX] Edit färben

[hoika]

Hallo,
mit dem Rechteck etwa so:

https://stackoverflow.com/questions/...-in-firemonkey

[Harry Stahl]

Zitat von hoika:

Hallo,
mit dem Rechteck etwa so:

https://stackoverflow.com/questions/...-in-firemonkey

Ja, so würde ich es auch machen.

Wenn Du dann dem in den Style eingefügten Rectangle den Stylenamen "RectangleStyleColor" gibst und zur Designzeit den jeweiligen Edits, die eine andere Hintergundfarbe benötigen, den entsprechenden StyleLookup für den Editstyle zugewiesen hast (z.B. "EditStyleColor"), kannst Du dem Retangle zur Laufzeit die benötigte Farbe zuweisen, mit Deiner Procedure von Nr. 1, nur etwas angepasst:

Delphi-Quellcode:

procedure SetEditColor(AEditControl: TCustomEdit; AColor: TAlphaColor);
var
  T: TFmxObject;
begin
  if Assigned(AEditControl) then
  begin
    T := AEditControl.FindStyleResource('RectangleStyleColor');
    if Assigned(T) and (T is TRectangle) then
       if Assigned(TRectangle(T).Fill) then
          TRectangle(T).Fill.Color := AColor;
    AEditControl.Repaint;
  end;
end;

Zur besseren Verständlichkeit ein kleines Demo anliegend (siehe auch screenshot), wo man zur Laufzeit dem aktiven Editfeld eine gewünschte Farbe zuweisen kann oder über die ausgewählte Farbe des Colorpickers.

Es sind natürlich auch noch andere Varianten möglich:

Den angelegten Style mehrfach kopieren und die Rectangels direkt mit den gewünschten Farben versehen. So kann man bereits zur Designzeit bestimmte Felder farblich gestalten. Zur Laufzeit könntest Du dann direkt mit dem StyleLookup-Property den gewünschten Style, bzw. Farbe zuweisen.

[himitsu]

Ich verstehe nur nicht was daran so schwer ist, die Farbproperty z.B. crNone crDefault einzurichten und wenn das abweicht (dort etwas angegeben wurde), dann nimmt der Style diese Frabe, anstatt seiner eigenen.

Diese "umständlichen" und extrem unintuitiven Krücken können doch nicht wahr sein und vor allmem, wozu gibt es dann überhaupt diese Property, wenn die niemand beachtet?



PS: Und jetzt mal versuchen mit "nativen" Komponenten zu arbeiten, anstatt mit diesem selbstgemalten Zeug und seinen "schrottigen" Styles.

[Harry Stahl]

Zitat von himitsu:

Ich verstehe nur nicht was daran so schwer ist, die Farbproperty z.B. crNone crDefault einzurichten und wenn das abweicht (dort etwas angegeben wurde), dann nimmt der Style diese Frabe, anstatt seiner eigenen.

Diese "umständlichen" und extrem unintuitiven Krücken können doch nicht wahr sein und vor allmem, wozu gibt es dann überhaupt diese Property, wenn die niemand beachtet?

Emba nimmt gerne Verbesserungsvorschläge entgegen. Wie wäre es hier mit einem entsprechenden Vorschlag von Dir?

[himitsu]

Mein Vorschlag ist doch einfach? Das was schon ständig alle suchen, also dass die vorhandenen Property für Color und Co. vom Style verwendet werden.

Alternativ einfach diese Property löschen und keiner fragt sich mehr, warum die nichts machen.


Hatte damals auch erstmal ewig suchen müssen, bis ich rausfand, wie man beim Panel den Border entfernt. (so wie man es seit Jahrzehnten in der VCL macht)
Da wurde man fast überall an die Styles verwiesen und dass man sich einen Eigenen bauen soll. (gut, mit TLayout ging es dann gleich einfacher)

[Sherlock]

Der Vorschlag macht sogar Sinn, vor allem wenn man mehr VCL-Entwickler zu FMX holen möchte. FMX hätte von Anfang an eine plattformübergreifende Variante von VCL sein sollen, alle Komponenten mit allen Properties. Stattdessen hat man bei FMX das Rad neu erfunden und dazu noch "im Betrieb" ständig die Spezifikationen geändert. Erst seitdem Delphi Ortsnamen hat, ist das recht stabil geworden. So hat man es sich mit einigen Leuten verscherzt, die jetzt erst langsam wieder kommen.

O'Neill

[Medium]

Ich antworte hier mal auf alle zusammen, jeden einzeln "durchquoten" würde etwas viel

Alle Lösungen die zusätzliche Komponenten erfordern (Transparent+Rect, Effekte) scheiden aus weil dadurch meine Datenversorgung ziemlich verkompliziert wird. Ich müsste quasi immer gucken ob ich die Farbe überhaupt setzen will, wenn ja ob es ein passendes Child- und/oder Parent-Objekt gibt, und stattdessen dann dieses nehmen. Geht zwar, würde aber wirklich fummelig im Rahmen meines sonstigen Frameworks und beim Formularbauen sehr unhandlich. (Randfrage: Überstrahlt das Glow dann nicht auch den Text?)

Die Lösungen von SO sind ja im Wesentlichen das, was ich schon probiert hatte. Das Problem bei den Styles ist ja, dass mir wie gesagt die Funktion FindStyleResource() mit nil zurück kommt. So kann ich da leider keinem Rectangle etwas zuweisen. Wenn DAS ginge, dann wäre mein Problem auf akzeptable Weise gelöst. (Eine statische Farbe kann ich so zwar machen, aber ich muss sie zur Laufzeit ändern können. Das ist das wichtigste.)

Beim OnPaint habe ich das Gefühl, dass mir da viel flöten geht was mir das OS abnimmt. Zum Beispiel wird bei der gezeigten Variante die Markierung überhaupt nicht gezeichnet wenn ich das richtig sehe. Das wäre verdammt nahe am ganz eigenen Edit, und wenn dann würde ich gleich zu letzterem tendieren weil man dann wirklich alles in der Hand hätte.

Ich probiere aber mal, wie das ist wenn ich nicht die originale "background"-Komponente im Style austausche, sondern ein Rectangle als Child von "content", wie in einem Beispiel gezeigt. Vielleicht finde ich das dann ja zur Laufzeit...

Danke euch!

[Harry Stahl]

Zitat von Medium:

Ich antworte hier mal auf alle zusammen, jeden einzeln "durchquoten" würde etwas viel

Das Problem bei den Styles ist ja, dass mir wie gesagt die Funktion FindStyleResource() mit nil zurück kommt. So kann ich da leider keinem Rectangle etwas zuweisen. Wenn DAS ginge, dann wäre mein Problem auf akzeptable Weise gelöst. (Eine statische Farbe kann ich so zwar machen, aber ich muss sie zur Laufzeit ändern können. Das ist das wichtigste.

Danke euch!

Wie gesagt, in dem von mir beigefügten Demo funktioniert es zur Laufzeit.

Wenn ich Deine zuerst versuchte Variante probiere (das ActiveStyleObject durch ein TRectangle ersetze und wieder in background umbenenne) wird bei mir das Object auch mit Deiner Original-Procedure gefunden. Möglicherweise liegt daher das Problem auch an anderer Stelle, die hier evtl. mit Deiner konkreten Implementation zu tun haben könnte. Davon abgesehen kann man dann zwar so die Farbe ändern, aber man sieht den Text nicht und hat kein Cursor-Blinken mehr.

Also ist der Weg mit dem Rectangle im Content eingefügt, der bessere Weg.

[Medium]

Cool, danke für's testen! Ich hoffe ich komme übers WE dazu da wieder dran zu gehen. Bin ja doch gespannt jetzt.

[himitsu]

Also bezüglich der Lösung mit anderen/angepassten Styles.
Hat schonmal jemand sowas versucht, wenn er das Programm mit mehreren umschaltbaren Styles betreibt?

Wäre es nicht echt umständlich, wenn man dann je Style auch noch zusätzlich Styles je Hintergrundfarbe bräuchte,
dann zur Laufzeit auch noch aufpassen muß den passtenden Style für die Farbe zu nutzen
und beim Upgrade, bzw. nächsten Totalumbau (seitens Emba) der Styles alles komplett wieder im Arsch ist.


@Medium: Die Komponenten ableiten und da dann das einbauen und programmseitig über ein eigenes Color-Property steuern.
Viele leiten einfach grundsätzlich erstmal alles ab, um dann später Änderungen und Bugfixes gleich überall zu haben.

Alternativ einen ClassHelper mit neuem Color/Style/Mode-Property, wo dann intern die jeweilige Änderung gemacht wird, was man später dann jeweils an die neue FMX-Version anpassen oder auf eine andere Variante ändern kann.