Delphi-PRAXiS
Seite 1 von 3  1 23      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   GUI-Design mit VCL / FireMonkey / Common Controls (https://www.delphipraxis.net/18-gui-design-mit-vcl-firemonkey-common-controls/)
-   -   [FMX] Edit färben (https://www.delphipraxis.net/196048-%5Bfmx%5D-edit-faerben.html)

Medium 18. Apr 2018 14:26

[FMX] Edit färben
 
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 18. Apr 2018 14:45

AW: [FMX] Edit färben
 
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 18. Apr 2018 14:54

AW: [FMX] Edit färben
 
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 18. Apr 2018 15:35

AW: [FMX] Edit färben
 
Bin ich froh, daß ich das dem OS bzw. Delphi überlasse.

Sherlock

Medium 18. Apr 2018 15:47

AW: [FMX] Edit färben
 
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 18. Apr 2018 17:01

AW: [FMX] Edit färben
 
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 18. Apr 2018 17:07

AW: [FMX] Edit färben
 
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 18. Apr 2018 18:23

AW: [FMX] Edit färben
 
Was heißt denn notfalls? Einen InnerGlow-Effekt drauf und gut ist. Wenn dir langweilig ist kannst du den sogar noch animieren.

KodeZwerg 18. Apr 2018 18:28

AW: [FMX] Edit färben
 
Könnte das helfen? Muss man halt nach Delphi portieren aber was ich da lesen ist nachvollziehbar. Auf OnPaint reagieren.

hoika 18. Apr 2018 18:38

AW: [FMX] Edit färben
 
Hallo,
mit dem Rechteck etwa so:

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


Alle Zeitangaben in WEZ +1. Es ist jetzt 01:28 Uhr.
Seite 1 von 3  1 23      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz