on[XYZ]-Methoden: Nicht aufrufen wenn Programmcode die Komponente ändert

[Furtbichler]

Ich persönlich glaube, das diese Problematik nur dann* auftritt, wenn man das VM-Muster (Viewmodel) nicht umsetzt.

Wegen der -bei korrektem Design- 1:1 Zuordnung von VM-Property und GUI-Control sollte bzw. muß dann imho jede Änderung des Controlzustandes (z.B. Setzen vom ItemIndex) die entsprechende Kaskade von OnXXXX-Ereignisaufrufen nach sich ziehen.

Zitat von Medium:

...Die netten Endlosschleifchen, ...

sollten bei der stringenten Umsetzung des Patterns nicht auftreten:

Delphi-Quellcode:

Procedure TMyViewModel.SetMyProperty (Const Value : TSomeType)
begin
  if Value = MyProperty Then exit;
  fMyProperty := Value;
  RaiseOnChaingeMyPropertyEvent;
end;

Einzige Ausnahme: Eine Double-Property verweigert gerne einmal den Endlosschleifenshowstopper If Value = MyValue then Exit wegen den bekannten Double-Gleichheits-Problematiken.

Wie gesagt: Man kann sämtliche Fallstricke und Performancebremsen durch saubere Programmierung des Viewmodels eliminieren, meiner Meinung nach.

Zitat von silver-moon-2000:

Delphi-Quellcode:

if Assigned(OnRadioGroupClick) and (not FDoNotTriggerEvents) then
  OnRadioGroupClick(...);

Tipp: Auf doppelte Verneinungen verzichten. In Bayern wird das anders verstanden. "Der soll jetzad kei' Trigger net feuan.'.

Besser:

Delphi-Quellcode:

if Assigned(OnRadioGroupClick) and FTriggerEvents then // Logik umkehren
  OnRadioGroupClick(...);
// Oder
if FDoNotTriggerEvents then exit; // Lesbarkeit erhöhen
if Assigned(OnRadioGroupClick) then
  OnRadioGroupClick(...);

Man sollte i.A. auf Flags à la 'NotXXX' verzichten, weil das Hirn beim Lesen mit solchen Verneinungen meist nicht so gut klar kommt. Hier ist das allerdings ok, denn das Flag definiert die Ausnahme von der Regel. Vielleicht wäre jedoch 'SurpressTrigger' ein besserer Name (gleiche Bedeutung, keine Verneinung).