Windows Message bei Änderung?

[idefix2]

Gibt es eigentlich eine Windows Message, die immer dann geschickt wird, wenn irgendwo im Formular der Inhalt eines WinControl verändert wurde?
Ich habe jetzt eine Weile gesucht, aber nichts gefunden.

[Bernhard Geyer]

Zitat von idefix2:

Gibt es eigentlich eine Windows Message, die immer dann geschickt wird, wenn irgendwo im Formular der Inhalt eines WinControl verändert wurde?
Ich habe jetzt eine Weile gesucht, aber nichts gefunden.

Definiere Inhalte eine WinControls?
Es wird viele Windows-Message geben die Gefeuert werden wenn was geändert wurde. Es gibt aber nicht die Broadcast-Windows-Message die immer gefeuert wird.

[himitsu]

Eine CheckBox feuert was anders, wenn sie an-/abgehackt wird und ob sie was auslöst, wenn man ihren Text ändert, weiß ich jetzt nicht.

Dagegen feuert ein Label, Edit, Panel und TForm die selbe Message, wenn man ihren Text (Caption, Text, Caption, Caption/Überschrifft) ändert.

Wann soll eine ListView welche einheitliche Message senden? (Änderung der Selection, Änderung der Items, ...)

[idefix2]

Ich habe auf jedem Formular zwei Buttons für "abbrechen" und "speichern".
Solange am Formular keine Änderungen gemacht worden sind, ist nur der "speichern"-button enabled und hat als Caption "schliessen" statt "speichern".
Sobald irgend welche Daten geändert worden sind (Text in einem Edit, Radiobutton-Status, checkbox-Status, egal was) werden beide Button aktiviert, und der User kann die Änderungen speichern oder mit "abbrechen" das Formular verlassen, ohne die Änderungen zu speichern.
Ich verwende jetzt einen Timer, der alle 200 Millisekunden alle Komponenten durchgeht und schaut, ob etwas geändert worden ist. Es gibt eine globale Message focuschanged, an die hatte ich die Prüfung vorher gehängt, aber das hat den Nachteil, dass der Button "Speichern" erst aktiviert wird, wenn der User die erste veränderte Komponente verlassen hat.
Sobald ich dazukomme, leite ich mir eigene Komponenten ab, die jede Änderung melden, aber dazu fehlt mir jetzt die Zeit. Wenn es leicht ginge, hätte ich gerne den Timer rausgeschmissen, aber wenn ich mich dafür in ein Dutzend verschiedene Windows Messages hängen müsste, dann lasse ich es fürs erste so, wie es ist.

[Perlsau]

Das würde ich mir nochmal überlegen ... Du hast doch irgendwelche Methoden, in denen die Eingaben des Anwenders verarbeitet werden. Werden diese Methoden aufgerufen, ist das ein sicheres Zeichen dafür, daß Änderungen stattfinden. Wieso nimmst du nicht einfach eine Boolsche Variable z.B. mit Namen Gesichert, die beim Programmstart und beim Speichern auf True gesetzt wird, bei Änderungen dagegen auf False? Wenn der Anwender nun das Programm zu beenden wünscht, fragst du im OnCloseQuery ab, ob Gesichert False ist, und wenn ja, dann fragst du den Anwender, ob die geänderten Daten gesichert werden sollen. In den Methoden, mit denen Daten verändert werden, setzt du dann Gesichert immer auf False.

[Popov]

@idefix2

Schon mal überlegt, dass du selbst eigene Messages definieren und verschicken kannst?

[idefix2]

Zitat von Perlsau:

Das würde ich mir nochmal überlegen ... Du hast doch irgendwelche Methoden, in denen die Eingaben des Anwenders verarbeitet werden.

Für die meisten der Komponenten nicht. Die Daten werden über unterschiedliche Komponenten (Edit, Combobobox, Radiobutton etc.) erfasst und beim Drücken des Buttons "speichern" ohne weitere spezielle Verarbeitung abgespeichert. Nur wenige Eingabefelder haben eigene Ereignisbehandlungsroutinen.

Zitat von Popov:

@idefix2
Schon mal überlegt, dass du selbst eigene Messages definieren und verschicken kannst?

Dazu müsste ich mir eben eigene Komponenten ableiten und statt der normalen Komponenten meine abgeleiteten verwenden. Das ist dann doch etwas mehr Arbeit.

[Perlsau]

Zitat von idefix2:

Zitat von Perlsau:

Das würde ich mir nochmal überlegen ... Du hast doch irgendwelche Methoden, in denen die Eingaben des Anwenders verarbeitet werden.

Für die meisten der Komponenten nicht. Die Daten werden über unterschiedliche Komponenten (Edit, Combobobox, Radiobutton etc.) erfasst und beim Drücken des Buttons "speichern" ohne weitere spezielle Verarbeitung abgespeichert. Nur wenige Eingabefelder haben eigene Ereignisbehandlungsroutinen.

Du speicherst Editfelder, ComboBoxen und RadioButtons direkt, verfügst also nicht über irgend eine Datenstruktur, die von deinen Edit-Komponenten bearbeitet werden kann? Das würde ja bedeuten, du speicherst deine Daten in visuellen Komponenten. Das halte ich für keine gute Idee ... Aber egal, mußt du letztendlich selber wissen, da möchte ich jetzt nicht länger drauf rumreiten.

Änderungen eines Editfeldes, einer ComboBox, eines Radio-Buttons etc. lösen OnChange aus: Du legst für all deine Edit-Komponenten dieselbe OnChange-Ereignisbehandlung fest. In dieser legst du dann die Information, daß etwas geändert wurde, fest. Du mußt auch keine Boolsche Variable neu deklarieren, denn du hast ja bereits eine in deinen Speichern-Button zur Verfügung, den du hier auf Enabled := True setzen kannst. Und schon hast du die Information, daß etwas geändert wurde oder daß alle Änderungen gespeichert sind, im Programm verfügbar. Nach dem Speichern führst du einfach Speicherbutten.Enabled := False aus.

[idefix2]

Natürlich speichere ich den Inhalt der diversen Felder und nicht die visuellen Komponenten.

Die Verwendung des Onchange ist von der Programmierung her recht fehleranfällig: wenn ich ein neues Feld einführe und auf die Zuweisung des Onchange vergesse, oder wenn ich ein spezielles Onchange brauche und dort auf das inherited vergesse, dann merke ich den Fehler nicht leicht.
Mit der Methode, die ich verwende, brauche ich mich um nichts zu kümmern. Das Programm merkt auch bei neu eingeführten Komponenten ohne irgend eine Zusatzprogrammierung, wann sie geändert worden sind.

[himitsu]

Andersrum ist es auch fehleranfällig.

Windows/Delphi ändert was oder du verwendest eine neue/andere Komponente, deren Message noch nicht behandelt wird, dann geht es ebenfalls nicht.

Andere Lösung:
Du leitest alle nötigen Komponenten ab, welche die nötigen Erweiterungen für die "Änderungsbehandlung" beinhalten. (z.B. TMyOptionsEdit, TMyOptionsCheckBox, ... -> IsChanged-Property und Notification an die Vorfahren-TMyOptionsForm oder eine TMyOptionsNotifier-Komponente auf der Form)

Und der Code ist später vielleicht auch mal plattformunabhängig, denn Android, iOS, Linux und Max haben irgendwie ihre Problemchen, mit den komischen Windows-Messages.