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

[Rollo62]

Ja also, dann liege ich ja nicht falsch wenn ich das stille Senden grundsätzlich Abschalten würde.
Ich sehe auch keinen echten Grund wo ich das unbedingt brauchen würde.

So hätte man zumindest ein konsistentes System, und müsste sich darüber gar keine Gedanken mehr machen.
.. und versehentliche Seiteneffekte fallen weg ..

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

Jupp, ich hab hier auch gern ein Konsistentes Verhalten, egal ob Benutzer oder das Programm was ändert.

Ausnahme:
* beim Laden von Daten, wo sich zwar der inhalt des Controls ändert, aber die Daten sich eigentlich nicht geändert haben
* und bei wechselseitigen Synchronisierungen, wo das OnChange eine Reaktion auslöst, was aber keine Endlosschleife erzeugen soll

[Rollo62]

Zitat:

* beim Laden von Daten, wo sich zwar der inhalt des Controls ändert, aber die Daten sich eigentlich nicht geändert haben

Das würde ich z.B. zumindest bei

Delphi-Quellcode:

  Checkbox.BeginUpdate;
  try
      Checkbox.IsChecked := xxx;
  finally
      Checkbox.EndUpdate;
  end;

erwarten, das schaltet die Events aber auch nicht ab.

[himitsu]

Nein, dies schaltet nur vorübergehend das Aktualisieren ab (Zugriff und Auslesen der Daten durch Oberflächenelemente) und im EndUpdate wird dann alles gemacht, was zwischendurch übersprungen wurde.

[Rollo62]

Ich hatte die Lösung von DevExpress nicht sehr geliebt (setzt ich schomn ein paar Jahre nicht mehr aktiv ein).
Die haben ja eine Art Zwischenschicht bei den Controls eingebaut wenn ich mich recht erinnere,
über die alle möglichen Properties gesteuert werden können.

Mittlerweile sehe ich das gar nicht mehr als so umständlich an.
Ein neues Property in allen Control, über das in konsistenter Weise das Control bedient wird.
Also sowas wie
    Checkbox.Conf.IsChecked := xxx; Das würde ermöglichen das alte System und das neue System parallel zu betreiben,
und damit einen schrittweisen Umstieg auf ein neues Konzept ermöglichen,
ohne viel Kopfzerbrechen

Womöglich auch eine gute Basis um damit ein MVVM System neu anzudenken ...

[himitsu]

Teilweise hab ich inzwischen ein paar neue Property, welche blos den Zugriff etwas umbiegen, nur noch ClassHelper drangehängt.
Es gibt noch ein paar wenige Oberflächen, wo die Basiskomponenten verwendet werden ... teilweise mit Absicht, aber so ist Dieses dann auch dort verfügbar.

Zitat:

Die haben ja eine Art Zwischenschicht bei den Controls eingebaut wenn ich mich recht erinnere,
über die alle möglichen Properties gesteuert werden können.

Per se ist das Konzept mit der Zwischenschicht OK, wenn es konsequent und einheitlich überall benutzt würde.

* TdxEdit ist nur ein Container und drin ist erst das TInnerEdit
* theoretisch könnten so auch in den Grids und Trees somit beim Colum-Editor die "selben" InnerEdits verwendet werden
* und wenn man nun eine Erweiterung für das InnerEdit machen täte, würden überall in Edits, Grids, TreeViews, ComboBoxen usw. diese drin sein

* praktisch ist das nicht so und an vielen Stellen nervt es nur noch
* auch dass viele der Komponenten tausendfach abgeleitet und in hunderten Subkomponenten verteilt sind, aber an anderen Stellen für viele Komponenden der selbe Code mehrmals als ungleiche Kopie drin steckt

[Rollo62]

ClassHelper reichen bei mir nicht immer (oder immer seltener).
Ich benutze oft Interposer um die Funktionalität der Basiskomponenten zu ergänzen.

Ich denke das man eine ganze Menge der "Unschönheiten" von Label, Button, Tree, Grid, etc. kapseln kann, und in ein einheitliches Konzept giessen.
Ganz neben bei erschlägt man damit auch noch Bugfixes und Workarounds auf den verschiedenen Platformen.

Ein einheitliches Interface, auf notwendigste glattgebügelt und einheitliches UI und Verhalten,
so das ein solches "Interface" womöglich sogar einheitlich abgeleitet werden kann
und damit von Label bis Grid über Planner abdecken könnte.
(Thema warum heisst es Caption statt Text, etc.)

Das Ganze funktioniert von FMX über VCL bis LCL, alles vereinheitlicht und kompatibel
(wäre schon, der Teufel liegt aber im Detail).

Ok, ich habe mit das TMS FNC noch nicht näher genauer angesehen, aber ich denke das
die das auch so ähnlich machen.
Nur benutzen die dann immer eigene "FNC"-Komponenten, das möchte ich aber nicht.

Ich schau mal wie weit man kommt

[himitsu]

Zitat:

Thema warum heisst es Caption statt Text, etc.

Das ist ein UND kein ODER.

Überall wo es Caption heißt, gibt es protected auch das Text und Beides geht auf's Selbe.
Fazit: Du kannst in der VCL fast alle Komponenten ab TWinControl nach TEdit casten, um den "Text" zu ändern oder auszulesen.
TEdit(xxx).Text := 'abc'; geht bei Label, TStaticText, ComboBox, GroupBox, TForm usw. und natürlich TEdit (alles was WM_SETTEXT benutzt)

Viel mehr nervt mich dass Caption ein TCaption ist und da das mit der Vererbung bei ClassHalper so garnicht funktioniert, fehlt dort dann der ganze StringsHelper dran.

[Rollo62]

Ok, dann wenn Dir das Caption-Beispiel nicht gefällt, dann eben "Top, Left" statt "Position.X/Y" ...
Du weisst was ich meine.

Was Du beschreibst ist nur ein Teil von dem wo ich mir eine saubere Lösung vorstelle, durch ein erweitertes API.

Ich denke aber das ursprüngliche Thema ist damit erledigt, da gibt es wohl keinen "großen Wurf" hinter dem Event-System der VCL/FMX.