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

[silver-moon-2000]

Um auch mal meinen Mist dazu zu geben, obwohl schon alles gesagt ist

Zitat von Codehunter:

Ich mache das meistens so, dass im jeweiligen Formular eine globale boolsche Variable existiert. Die wird abgefragt wenn ein OnClick oder sonstwas ausgeführt wird. Bei Operationen, die keine Eventhandler auslösen sollen, wird die Variable vorher gesetzt und am Ende der Operation wieder zurückgesetzt.

Genauso mache ich das eigentlich auch:

"in der Logik"

Delphi-Quellcode:

//Feststellen, dass etwas in der GUI geändert werden muss
GUI.DoNotTriggerEvents := True;
//Änderungen in der GUI vornehmen
GUI.DoNotTriggerEvents := False;

"in der GUI"

Delphi-Quellcode:

private
  FDoNotTriggerEvents : Boolean;
public
  property DoNotTriggerEvents ...

[...]

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

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

[jaenicke]

Zitat von Furtbichler:

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

Einen Double vergleicht man ja auch mit SameValue.

[Medium]

Zitat von Furtbichler:

Zitat von Medium:

...Die netten Endlosschleifchen, ...

sollten bei der stringenten Umsetzung des Patterns nicht auftreten:

Volle Zustimmung. Aber jetzt bringe das mal den VCL-Entwicklern bei, und wir haben was gewonnen

[Furtbichler]

Zitat von jaenicke:

Einen Double vergleicht man ja auch mit SameValue.

Mir schon klar, aber mein Pattern lautete If Value=fMyProperty then... und nicht If SameValue(fMyProperty,Value) then... , deshalb also der explizite Hinweis. Ich hätte den Hinweis auch auf Objekte erweitern können, aber das habe ich mir geschenkt. Da bei Double-Werten jedoch hin und wieder noch die Frage aufkommt, wieso '=' nicht funktioniert, habe ich das dann kurz und knapp angerissen. Bei Erwähnung von 'SameValue' hätte ich ausholen müssen, bei Weglassen meines knappen Zusatzes wäre ein ganz Schlauer auf die Idee gekommen, mich auf die Double-Problematik hinzuweisen, also habe ich wirklich gedacht, der kurze Hinweis reicht. Tut er wohl nicht.

Zitat von Medium:

Zitat von Furtbichler:

Zitat von Medium:

...Die netten Endlosschleifchen, ...

sollten bei der stringenten Umsetzung des Patterns nicht auftreten:

Volle Zustimmung. Aber jetzt bringe das mal den VCL-Entwicklern bei, und wir haben was gewonnen

Meinst Du mit 'VCL-Entwicklern' die Entwickler der VCL? Ich bin der festen Überzeugung, das man auch verbuggte VCL-Eventkaskaden etc. über ein gut implementiertes VM-Pattern lösen kann.

Oder meinst Du mit 'VCL-Entwicklern' Entwickler, die mit der VCL entwickeln? Wenn Sie unter deiner Leitung arbeiten, dann chleudere die Purchen su Poden. Arbeiten sie nicht mit/für Dich, dann... Pech gehabt und weiter den linken Schuh ausziehen (aka den Messias spielen).

Leider gibt es hier in der DP kein Dojo, wo man sich mit solchen Implementierungen auseinandersetzen und robuste Pattern entwickeln kann.