Eine Alternative könnte natürlich auch sein, dass beim Zuweisen der OnChange-Routine zur Laufzeit erstmal geprüft wird, ob EditXYZ schon eine eigene OnChange-Routine hat. Dann wird diesem Edit die globale OnChange halt nicht zugewiesen.
Dann muss man natürlich bedenken, in der speziellen OnChange-Routine der Edits auch das zu machen, was auch die globale Routine macht. Am einfachtsen in dem in beiden Fällen eine "normale" (nicht Event bezogene) Prozedur aufgerufen wird, die den eigentlichen Code enthält.
Ja, so ginge es auch - aber:
Die Programme sind wesentlich länger im Einsatz, als ich mich an den Code, den ich "damals" verbrochen habe, erinnern würde - und gar erst, wenn irgendwann ein anderer Programmierer Änderungen in dem Code machen muss. Der baut dann in ein Feld eine OnChange Behandlung ein und wundert sich, warum plötzlich der "Speichern"-Button nicht mehr aktiviert wird, obwohl das Feld geändert worden ist (oder noch schlechter, der Kunde wundert sich, nachdem das Update eingespielt worden ist). Wenn ich separate OnChange Routinen einfach verbiete, verlange, dass OnChange Behandlungen nur in der zentralen Routine erfolgen dürfen (wenn "sender" den entsprechenden Wert hat) und eine verständliche Warnung/Fehlermeldung ausgebe, wenn die Form beim Programmstart auf eine Komponente stösst, bei der schon im
OI eine OnChangeBehandlung eingegeben wurde, dann entschärft das das Problem.
Eventuell kann man sich das Leben aber auch evtl. einfacher machen, wenn man mit Actions arbeitet, da das OnUpdate(?)-Ereignis der Actions doch alle Nase lang gefeuert wird.
Ja, so könnte ich mir auch meinen Timer sparen. Statt an die Timer Routine könnte ich die Überprüfung an die OnUpdate Routine der entsprechenden Actions hängen. Aber der Ansatz von Dalai gefällt mir noch besser.