Windows Message bei Änderung?

[idefix2]

@Dalai
Das würde heissen, dass man individuelle Onchange-Behandlungen auch in der zentralen Routine erledigen muss, wenn man wirklich einmal ausnahmsweise solche braucht, und den einzelnen Kompos eben keine Onchange Ereignisse zuordnen darf - Ja, das scheint mir ganz praktikabel zu sein, die Lösung gefällt mir immer besser .

Und wenn irgendwer, der zwei Jahre später am Formular eine Änderung macht, auf diese Einschränkung vergisst, dann könnte man im OnCreate des Forms eine passende Warnmeldung ausgeben, wenn OnChange bei einer Komponente schon zugeordnet ist. Und hoffen, dass er das Programm nach der Änderung zumindest einmal startet, bevor es an die Kunden ausgeliefert wird

Zitat von Captnemo:

Deswegen würde ich so was auch nicht machen. Wenn man später eigene OnChange-Ereignisse für bestimmte controls braucht muss man wieder alles umstricken, und dann wird's unübersichtlich.

Siehe Lösungsansatz von Dalai. Da braucht man dann nichts umzustricken.

[Captnemo]

Zitat von idefix2:

Zitat von Captnemo:

Deswegen würde ich so was auch nicht machen. Wenn man später eigene OnChange-Ereignisse für bestimmte controls braucht muss man wieder alles umstricken, und dann wird's unübersichtlich.

Siehe Lösungsansatz von Dalai. Da braucht man dann nichts umzustricken.

Wieso nicht?

Zitat von Dalai:

Delphi-Quellcode:

procedure TForm1.ToggleChangeEventHandlers(Enable: Boolean);
var tne: TNotifyEvent;
begin
    if Enable then
       tne:= SetPropertiesChanged
    else
       tne:= nil;

    //--- Set all OnChange/OnClick event handlers
    editName.OnChange:= tne;
    editCommandLine.OnChange:= tne;
    checkEnabled.OnClick:= tne;
    editComments.OnChange:= tne;
    comboShowWindow.OnChange:= tne;
    comboLocation.OnChange:= tne;
end;

Und wenn du jetzt z.B. für editName noch prüfen willst, ob .text<>'' ist, dann brauchst du doch auch einen eigene Behandlungsroutine.

[idefix2]

Die Prüfung mache ich eben für das eine Feld auch in der zentralen Routine:

Zitat von Dalai:

Delphi-Quellcode:

procedure TForm1.SetPropertiesChanged(Sender: TObject);
begin
    btnApply.Enabled:= True;
    if Sender = comboLocation then
        checkCopyStartup.Enabled:= True;
end;

Für diese eine Komponente (ComboBox) gibt's in der Ereignisbehandlung zusätzlich eine Besonderheit.

Nachdem spezielle OnChange-Behandlungen eher selten nötig sein werden, ist die Einschränkung nicht wirklich wichtig. Gültigkeitsprüfungen gehören ja zum Beispiel meiner Meinung nach ins OnExit und nicht ins OnChange.

[Jumpy]

Zitat von idefix2:

Die Prüfung mache ich eben für das eine Feld auch in der zentralen Routine:

Zitat von Dalai:

Delphi-Quellcode:

procedure TForm1.SetPropertiesChanged(Sender: TObject);
begin
    btnApply.Enabled:= True;
    if Sender = comboLocation then
        checkCopyStartup.Enabled:= True;
end;

Für diese eine Komponente (ComboBox) gibt's in der Ereignisbehandlung zusätzlich eine Besonderheit.

Nachdem spezielle OnChange-Behandlungen eher selten nötig sein werden, ist die Einschränkung nicht wirklich wichtig. Gültigkeitsprüfungen gehören ja zum Beispiel meiner Meinung nach ins OnExit und nicht ins OnChange.

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.


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.

[idefix2]

Zitat von Jumpy:

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.

Zitat von Jumpy:

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.

[Dalai]

Zitat von Captnemo:

Und wenn du jetzt z.B. für editName noch prüfen willst, ob .text<>'' ist, dann brauchst du doch auch einen eigene Behandlungsroutine.

Das erledigt die eigentliche Speicher-Routine, die beim Klick auf den Apply- oder OK-Button ausgelöst wird. Klar, könnte man auch im OnChange-Ereignis machen. Ich hab lieber alles zentral, so dass vor dem Speichern die Eingaben geprüft werden.

MfG Dalai

PS: Die Prüfung auf leeren String hab ich ganz vergessen in meiner Anwendung. Danke für den Hinweis .