Hallo zusammen,

um es gleich vorweg zunehmen, ich kenne mich mit TAction, Events, etc. aus und weiss damit umzugehen.

Weil ich mal wieder darüber gestolpert bin:

Was ich nicht verstehe ist warum die Events in Controls nicht nur via Benutzereingaben gefeuert werden ?
Z.B. eine Checkbox in FMX feuert auch den OnChange Event wenn man Checkbox.IsChecked ändert.

Das kann zu üblen Seiteneffekten führen, und ich würde das Feuern per Code eigentlich generell immer abschalten.

Das heisst:
Control --> geändert durch Eingabe --> Events sollen feuern (OK)
Control --> geändert per Runtime Code --> Events sollen NICHT feuern (das tun sie aber doch)

Änderungen per Code sollten doch zur Konfiguration der Controls nutzbar sein, ohne gleich alle möglichen Seiteneffekte zu triggern.

Was ich gerne wissen möchte ist, ob hinter diesem aktuellen Verhalten vielleicht ein größeres Konzept oder Pattern steht,
und warum das direkte Feuern per Code womöglich doch Sinn machen könnte ?

Vielleicht in einem M(V/P)M Konzept könnte das Feuern Sinn machen, obwohl ich das auch nicht unbedingt sehen kann.
Auch hier sehe ich sinnvollerweise zwei Schichten:
1. die Änderung via Code und 2. das Triggern von Events wenn modified, bei Bedarf.

Warum wurde das Framework so designed dass dieses direkte Feuern per Code kommt ?

Ich denke mal, das wurde so implementiert, weil es auch in der VCL so ist. Dort ist es so, weil es eine Windows Control ist, welche sich so verhält. Und um es dem eingefleischten Delphi-Entwickler leichter zu machen, wurde das Verhalten so übernommen.

......

Ja schon, könnte sein.
Aber gibt es dafür nicht irgendein übergeordnetes Konzept oder Design-Pattern ?

Die FMX Checkbox ist ein denkbar schlechtes Beispiel, denn genau die ist bei den angesprochenen Events genau richtig:
- OnClick - wenn der Nutzer drauf klickt
- OnChange - wenn sich der Wert ändert, egal ob durch UI Interaktion oder Code
- OnExecute einer zugewiesenen TAction hängt sich an das OnClick

Dahingehend ist die VCL Checkbox eine Katastrophe, denn dort sind Anklicken und Wert ändern miteinander verwurschtelt und beides Triggert OnClick

In der VCL wird beim MyCheckBox.Checked := True; sogar ein OnClick ausgelöst. (das arbeitet dort wie ein OnChange, was es nicht gibt)

Da wir eh alle Komponenten immer abgeleitet haben,
konnen wir hier an zentraler Stelle ein CheckedNoClick einbauen, wo bei Zuweisung kurz das Event abgehängt wird.

Zitat von Stevie:

- OnChange - wenn sich der Wert ändert, egal ob durch UI Interaktion oder Code

Ok, wenn man das getrennt sieht OnClick/OnChange könnte ein Schuh daraus werden.
Aber macht es überhaupt Sinn das Triggern durch den Code ?

Ist das jetzt Gut oder Schlecht das es triggert ?

Zitat von himitsu:

..
konnen wir hier an zentraler Stelle ein CheckedNoClick einbauen

Ja genau, ich baue mir auch die passenden Properties ein
hier z.B.

markieren

Delphi-Quellcode:

  //1.
  Checkbox.IsChecked := xxx; // Standard, immer OnChange
  Checkbox.IsChecked_Quiet := xxx; // Neu: immer Silent

Weil ich dann immer diese doppelten Properties habe denke ich, sollte ich nicht so ändern:

markieren

Delphi-Quellcode:

  //2.
  Checkbox.IsChecked := xxx; // Geändert, immer Silent
  Checkbox.IsChecked_Notify := xxx; // Neu: immer OnChange (wie altes Verhalten)

Wohlgemerkt das ist jetzt nur ein Beispeil (Checkbox), das zieht sich aber durch alle Komponenten.
Macht es Sinn das für alle Komponenten anzupassen, so dass das Verhalten wie 2. ist ?

Zitat von himitsu:

In der VCL wird beim MyCheckBox.Checked := True; sogar ein OnClick ausgelöst. (das arbeitet dort wie ein OnChange, was es nicht gibt)

Da wir eh alle Komponenten immer abgeleitet haben,
konnen wir hier an zentraler Stelle ein CheckedNoClick einbauen, wo bei Zuweisung kurz das Event abgehängt wird.

Das kannst'e einfacher haben! TButtonControl , von dem z.B. TButton , TCheckBox und TRadioButton abgeleitet sind, hat ein protected Property ClicksDisabled , mit dem man das verhindern kann.

Zitat von Uwe Raabe:

at ein protected Property ClicksDisabled , mit dem man das verhindern kann.

Das kenne ich auch, finde ich aber vom Verhalten/Bezeichnung her völlig Unintuitiv.

Deshalb möchte ich ja generell diese Events per code abschalten, was spräche dagegen ?
Umgekehrt, wenn ich was triggern möchte dann muss ich das bewusst tun.

Als ich mal Controls erstellt habe, hatte ich die Properties normal mit Gettern (_get_Xyz) und Settern (_set_Xyz) incl. Benachrichtigungen erstellt und zusätzlich eine Methode SetXyz(Value...) bereitgestellt für stille Änderungen und Initialisierungen.

Hey, das war doch nur ein Beispiel aus einem uralten Programm, welches noch Altlasten von vor 25 mitschleppt
und was auch über Tastatur bedienbar sein soll und, wo man von Userseite bei der Leertaste denoch das OnClick haben will, trots Delphi XE, DevExpress und ein paar Win10 im Win2000-Look.

Vielleicht vermutlich eventuell komm ich dieses ja mal dazu unser Programm auf 10.x zu migrieren.
73 EXE/DLL/BPL, 475 inkl. Fremdkomponenten und 557 eigene PAS ... da braucht es einfache zentrale Lösungen.
Vor paar Jahren hatte ich schonmal von D7 auf XE und ein Vorgänger von TurboPascal zu Delphi.
Und natürlich muß sich das Programm für die alten Hasen noch genauso mit Tastatur bedienen lassen, wie damals im DOS.
Auch neue Eingabefelder sollten den "eingeschleiften" Workflow nicht verändern, aber dennoch sollen zugleich auch aktuellere Gestaltungsmittel Einzug finden usw.