Windows Message bei Änderung?

[TRomano]

Ich habe mir das nun alles durchgelesen und bin ein wenig verwundert ...wenn man in der DP etwas erfragt und von wirklich, langjährig erfolgreichen, Entwicklern Konzepte vorgeschlagen bekommt sollte man wenigstens mal in sich gehen und darüber nachdenken.
In deinem Falle, und so lange Du dir keine Ableitungen von den Komponenten machst, würde ich mir, wenn es schnell gehen soll, einen Dictionary mit den Start- und aktuellen Werten anlegen. In einer zentralen OnChange-Routine kannst Du dann prüfen, ob es überhaupt Änderungen gibt und entsprechend deine Buttons einstellen. Es könnte ja auch sein, dass der User eine Eingabe wieder zurückstellt ...
Oder Du nimmst halt gleich daten-sensitive Controls (da kann man auf xxx.OldValue <> xxx.NewValue prüfen) und checkst in einer zentralen Rotine, ob sich etwas geändert hatte ...

[TRomano]

@IdeFix2: ich glaube, dass ich mich jetzt da auch raushalte, denn ich finde es unmöglich, wie Du hier mit den Foren-Usern sprichst, denn man versucht Dir zu helfen und es sind ausgesprochen patzige Antworten. Ich kann auch nicht erkennen, dass Du nach 30 Jahren Berufserfahrung (egal welche Sprache) dein Problem in ein einfaches, aber sicheres, Konzept umsetzt.

[idefix2]

Zitat von Dalai:

Wieso weist du nicht beim Erstellen/Anzeigen des Formulars oder beim Befüllen der Komponenten das OnChange zu? So mache ich das jedenfalls. Klar kann man da die eine oder andere Komponente vergessen, aber das fällt doch sofort auf, wenn sich der Speichern-Button nicht ändert beim Ändern eben dieser Komponente.
...
Alles ist zentral in dieser Methode. Das hat sogar den Vorteil, dass man temporär alle Behandlungsroutinen abschalten kann, wenn man es braucht (z.B. Speichervorgang).

MfG Dalai

Hmm, das wäre auch ein Ansatz, der mir gefallen könnte. Lässt sich noch weiter verbessern, dass man neue Komponenten an der Stelle nicht manuell einfügen muss:

Delphi-Quellcode:

for i:=0 to componentcount-1 do
    if component[i]=Tedit then Tedit(component[i]).onchange:=tne
    else  
    if component[i]=Tcheckbox then TCheckbox(component[i]).onchange:=tne
    ...

Ein Problem hätte ich dann nur, wenn es Komponenten gibt, die eine eigene Onchange-Routine brauchen, in der noch irgend etwas anderes passieren soll.

[Dalai]

Zitat von idefix2:

Ein Problem hätte ich dann nur, wenn es Komponenten gibt, die eine eigene Onchange-Routine brauchen, in der noch irgend etwas anderes passieren soll.

Auch kein Problem, das sich nicht lösen lässt. Beispiel:

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.

MfG Dalai

[Captnemo]

Zitat von idefix2:

Delphi-Quellcode:

for i:=0 to componentcount-1 do
    if component[i]=Tedit then Tedit(component[i]).onchange:=tne
    else  
    if component[i]=Tcheckbox then TCheckbox(component[i]).onchange:=tne
    ...

Ein Problem hätte ich dann nur, wenn es Komponenten gibt, die eine eigene Onchange-Routine brauchen, in der noch irgend etwas anderes passieren soll.

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.

Hängt natürlich immer davon ab, wie man so arbeitet. Ich persönlich arbeite bei Formularen, denen ich einen solche Logik spendieren möchte, im Formular mit einer Kopie der Originaldaten. Bei Änderungen vergleiche ich dann die Kopie komplett mit dem Original und erkenne so Änderungen, aber auch wenn Änderungen wieder zurückgenommen wurde, und setze meine Buttons entsprechend.

[idefix2]

Zitat von TRomano:

@IdeFix2: ich glaube, dass ich mich jetzt da auch raushalte, denn ich finde es unmöglich, wie Du hier mit den Foren-Usern sprichst, denn man versucht Dir zu helfen und es sind ausgesprochen patzige Antworten.

"mit den Foren-Usern" ist wohl sicher nicht zutreffend. Ich bin für jeden konstruktiven Vorschlag dankbar.

Zitat:

Ich kann auch nicht erkennen, dass Du nach 30 Jahren Berufserfahrung (egal welche Sprache) dein Problem in ein einfaches, aber sicheres, Konzept umsetzt.

Dazu spare ich mir einen weiteren Kommentar.

Zitat von TRomano:

In deinem Falle, und so lange Du dir keine Ableitungen von den Komponenten machst, würde ich mir, wenn es schnell gehen soll, einen Dictionary mit den Start- und aktuellen Werten anlegen. In einer zentralen OnChange-Routine kannst Du dann prüfen, ob es überhaupt Änderungen gibt und entsprechend deine Buttons einstellen. Es könnte ja auch sein, dass der User eine Eingabe wieder zurückstellt ...

Genau das mache ich ja. Es geht ja nur darum, sicherzustellen, dass diese "zentrale On-Change Routine" auch wirklich allen Komponenten zugeordnet ist. Deshalb hatte ich nach so einer globalen Windows-Message gefragt, an die ich den Event hängen wollte. Aus Erfahrung weiss ich, dass jeder Eintrag, den man jedesmal erneut von Hand machen muss, irgendwann bei einer Programmänderung vergessen wird. Der Ansatz von Dalai wäre allerdings eine gute Alternative zu meinem Timer. Der Vorteil wäre, dass er nur aufgerufen wird, wenn wirklich irgendwo eine Änderung stattgefunden hat, und nicht ständig alle 200ms, der Nachteil, dass er sich mit spezifischen On-Change Events nicht vertragen würde, sollte man solche irgendwo brauchen (was bei mir derzeit nicht der Fall ist, aber im Prinzip könnte das irgendwann sein).

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

Aus Erfahrung weiss ich, dass jeder Eintrag, den man jedesmal erneut von Hand machen muss, irgendwann bei einer Programmänderung vergessen wird.

Ich gehe mal davon aus, dass du deine Eingabecontrols auf der Form selbst setzt. Dann musst du doch sowieso "Hand" anlegen, um z.B. das Control auszurichten, bestimmte Eigenschaften zu setzen, usw. Was spricht dagegen, im dann auch im OnClick oder im OnChange auf Veränderung zu prüfen.

Noch eine Idee: Du könntest das Tag jedes Controls nutzen. In einer zentralen Routine addierst du die Tag's aller Komponenten. Wenn das Ergebnis größer 0 ist, dass speichern. Dann musst du zwar immer noch für alle Controls ein Ereignis haben, was den Tag verändert und dann die zentrale Routine aufruft, aber du brauchst in der Zentralen Routine nix ändern.

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