[FMX] Edit färben

[Medium]

Huhu DP.

FMX, oder genauer gesagt die Styles, machen mich eines Tages noch malle im Kopp. Ich portiere gerade eine unserer Anwendungen von D2007 auf 10.2.3 mit FMX. In unserem Programm wird über die Farbe des Hintergrundes von Edits eine Menge an Infos an die User gegeben. (Spezialanwendung für geschultes Fachpersonal, bitte keine Diskussion über "...aber Standard!!".)

Das tolle am FMX.TEdit: Es hat gar keine Color-Property mehr! Also bin ich auf die Suche gegangen, und habe den folgenden Schnipsel aufgetrieben:

Delphi-Quellcode:

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

"Geil!", dachte ich mir, Problem gelöst! Zwar sehe ich dann beim Editieren des Formulars manche Farben nicht mehr, aber sei's drum.

Dann aber habe ich das mal ausführen lassen, und musste feststellen, dass da nichts geändert wurde. Kurzes Debuggen: FindStyleResource() kommt mit nil zurück. Mal den Style eines Edits im StyleEditor aufgerufen, und siehe da: Es GIBT eine Ressource mit dem Namen "background". Warum wird diese dann nicht gefunden?

Aber es kommt noch schlimmer. Die o.g. Prozedur ist offenbar für ein älteres Delphi geschrieben. Für eines, wo TEdit noch mit einem TRectangle gestyled wurde. In 10.2.3 aber ist der Typ des "background"-Objektes "TActiveStyleObject", und darin wird auf ein Bitmap verwiesen!
Ja wie bescheuert ist DAS denn!? Da hat man ein tolles vektorbasiertes GUI Framework, und holt sich durch die Hintertür wieder klobige Rasterbilder ins Boot? Wer kam auf den Quark? Und NOCH viel schlimmer ist: Wie soll man den JETZT bitte noch die Farbe ändern? Soll ich nun für alle meine ~8 Farben einen eigenen Style machen (mit einem völlig unterentwickelten Style-Designer)? Bevor ich mich mit dem Kram nochmals herum ärgere, schreibe ich mir fast lieber meine eigene Edit-Komponente...

Aber lieber wäre es mir ja, wenn jemand hier noch einen guten Rat für mich hätte, wie es ggf. doch geht. Vor allem weil ich sehr gerne auch die TNumberBox für rein numerische Eingaben in ähnlicher Weise behandeln möchte.

Oder gibt es ggf. für günstig Edits die solche Funktionalität auch bieten und ... deren Farbe man gnädigerweise ändern darf?

[timog]

Ich leide mit Dir. Wir haben das mal wie hier bei SO versucht:

Eigenen Style bearbeiten, dann unter Content ein neues Rechteck Objekt eingefügt, formatieren und das dann stylen. Hat man natürlich das Geraffel mit Stylebooks und den so schön von Dir beschriebenen Editor :-)

Suche nach anderen Komponenten haben wir aufgegeben - wäre auch so, als würde man gegen das Framework arbeiten. Ist halt unter FMX ein komplett anderer Ansatz, als wir von der VCL gewohnt/verwöhnt waren/sind.

Ein Tutorial FMX für VCL Entwickler wäre mal ein netter Gedanke...

[Medium]

Ich habe jetzt mal ganz frech im Standardstil für TEdit das "background"-Objekt gelöscht und mein eigenes TRectangle eingefügt und "background" genannt. Das geht an sich auch. Nur leider findet die o.g. Funktion FindStyleResource() noch immer keine Ressource mit dem namen "background", womit dieser Weg weiterhin versperrt bleibt.

Das dumme ist jetzt: Meine Migration (die gleichzeitig eine recht umfangreiche Erweiterung ist) ist schon recht weit gediegen. Das kann ich nun nicht noch wieder auf VCL zurück jodeln. Das gibt allein der Zeitplan schon nicht her. Aber wenn ich jetzt mit alternativen Darstellungen anrücke, maulen uns die Bediener beim Kunden wieder voll und wir haben 2 Monate Support-Anrufe weil's mal wieder keiner kapiert wenn etwas 5% anders ist als die 15 Jahre davor... Mag ja machbar sein, aber wir würden uns unseren guten Ruf ganz gern beibehalten.


Edit: Kleine Info am Rande: Versucht BLOß nicht eine Ableitung von TFrame unterzujubeln!! Dann begürbelt sich die IDE fürchterlich, und glaubt halb daran, dass es eigentlich ein TForm ist, und versucht beim Laden oder zur Runtime dessen Properties beim Frame zu finden, was natürlich knallt. Aber wie gesagt nur am Rande.

[Sherlock]

Bin ich froh, daß ich das dem OS bzw. Delphi überlasse.

Sherlock

[Medium]

Sehr schön für dich. Wie würdest du dann folgendes machen: Wir haben sehr oft Soll-/Ist-Wert Paare, durch welche Maschinenparameter eingestellt bzw. nachgesehen werden. Wir haben über die letzten ~20 Jahre bei dem Kunden werks-weit den Standard, dass Felder, in denen etwas vom Bediener eingegeben werden kann, Hellgelb hinterlegt sind durchgezogen. Somit weiß jeder dort bei jeder Anlage an jeder Bedienstation: Hellgelb = Ich muss da was eintragen. Die Ist-Wert-Ausgabe ist Weiß.
Wie kann ich nun Windows sagen, dass es manche Edits in unserem Soll-Wert-Stil zeichnen soll?

Anderer Fall: Ausgabe von Messwerten. Die Geräte geben oftmals nicht nur einen reinen Wert aus, sondern auch ein Störungssignal. Alle Bediener dort wissen: Wenn das Feld Rot hinterlegt ist, ist der Wert gestört und ein Elektriker muss anrücken. Oft sind diese Anzeigen auch an ohnehin schon recht wild aussehenden Stellen, sodass eine zusätzliche Anzeige (wohlmöglich noch mit Text) genau das Gegenteil von dem erreicht, was die ganze Schose soll: Übersichtlichkeit schaffen.
Wie teile ich dies meinem OS mit?

Dadurch, dass wir das in vielen Belangen in allen Teil-Anlagen bei dem Kunden durchgezogen haben, können die Mitarbeiter eines Betriebes z.B. bei Krankheit fast ohne Umstellung in allen anderen Betrieben bedienen. Wenn ich jetzt EINE von ~80 Bedienstationen anders mache. Ja rate mal was dann los ist.


Aber lass mal. Einen eigenen Button musste ich mir auch schon machen, da dieser ähnliche Probleme machte. Bald bin ich so weit, dass ich gar keine Standardkomponenten mehr einsetze. SO war das eigentlich nicht gedacht, als ich mich schweren Herzens doch kürzlich dazu entschieden habe doch wieder Delphi einzusetzen. Wenn ich eh alles zu Fuß neu machen muss...

[timog]

Vielleicht noch ein Vorschlag: Ein TRectangle als Container für das TEdit nehmen? Ich meine damit, das TEdit in der Strukturansicht verschachteln - den Parent des TEdits auf das TRectangle ändern. Dann das StyleLookup des TEdits auf transparentedit. Damit wird die Fill.Color des TRectangle sichtbar und Du kannst über den Parent des TEdits die Farbe ändern, vereinfacht also etwa so:

Delphi-Quellcode:

(Edit1.ParentControl AS TRectangle).Fill.Color:=claAqua;

Sind dann halt zwei Standardkomponenten aus denen man sich eine neue baut.

[himitsu]

Zitat:

Wie würdest du dann folgendes machen ...

Notfalls kannst du mit Umrandungen arbeiten (Blur/Glow), anstatt den Inhalt zu färben.

Nur in Grids/Listen geht sowas natürlich nicht für einzelne Felder.

[Der schöne Günther]

Was heißt denn notfalls? Einen InnerGlow-Effekt drauf und gut ist. Wenn dir langweilig ist kannst du den sogar noch animieren.

[KodeZwerg]

Könnte das helfen? Muss man halt nach Delphi portieren aber was ich da lesen ist nachvollziehbar. Auf OnPaint reagieren.

[hoika]

Hallo,
mit dem Rechteck etwa so:

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

[Sherlock]

Zitat:

Zitat von himitsu (Beitrag 1399729)

Zitat:

Wie würdest du dann folgendes machen ...

Notfalls kannst du mit Umrandungen arbeiten (Blur), anstatt den Inhalt zu färben.

Nur in Grids/Listen geht sowas natürlich nicht für einzelne Felder.

Genau so. Und in Grids könnte man probieren Controls in die Felder zu platzieren.

Sherlock

[Rollo62]

Was spricht gegen Custom Style?

[Der schöne Günther]

Was spricht gegen einen Farbeffekt den man an- und ausmacht? Ist eine Zeile, ist verständlich und funktioniert auch (hoffentlich) in kommenden Versionen noch. 8-)

[Harry Stahl]

Zitat:

Zitat von hoika (Beitrag 1399743)

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:

Zitat von himitsu (Beitrag 1399956)

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. :roll:


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:

Zitat von Medium (Beitrag 1400008)

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.