Design Konzept/Pattern hinter TAction, Events, Controls mit Seiteneffekten ?

[sakura]

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.

......

[Rollo62]

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

[Stevie]

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

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

[Rollo62]

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.

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:

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 ?

[Uwe Raabe]

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.

[Rollo62]

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.

[stahli]

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.

[Uwe Raabe]

Zitat von Rollo62:

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

Immerhin ist derselbe Mechanismus, den auch eine TAction (genauer ein TButtonActionLink) einsetzt, um das Auslösen des Click-Event zu verhindern. Insofern sehe ich weder eine Notwendigkeit noch einen Vorteil darin, hier einen zusätzlichen Mechanismus einzusetzen.

Bei einer TCheckBox werden damit ja sowohl der OnChange- als auch der OnClick-Event verhindert.

Einfach das OnClick abhängen reicht aber auch nicht immer. Bei letzterem kann es sich ja auch um das OnExecute einer TAction handeln. Dann würde das temporäre entfernen des Events gar nichts bringen, da der ActionLink immer noch vorhanden ist.

[himitsu]

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.