Windows Message bei Änderung?

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

[idefix2]

@himitsu
Das Ableiten von eigenen Komponenten steht auf meiner to-do List.

Wenn es eine Windowsmessage 'somethinghaschanged' geben würde, die bei jeder Änderung des Inhalts eines beliebigen Wincontrol gefeuert würde, dann würde ich mich schon darauf verlassen wollen, dass die bei jeder Art von Wincontrol und bei jeder Änderung des Inhalts uch in zukünftigen Windows-Versionen gefeuert wird. Nachdem es die nicht gibt, sind weitere Überlegungen in der Richtung ohnedies hinfällig.

Die Verwendung eines neuen/anderen Komponententyps kommt ungleich seltener vor als die Einführung eines neuen z.B. Editfelds. Wenn ich in meiner Form einen neuen Komponententyp verwende, den ich bisher in der Überprüfung von Änderungen noch nicht berücksichtigt habe, dann muss ich mich um den natürlich kümmern, aber das ist doch eher eine seltene Ausnahme.

@perlsau

Zitat:

Wenn ja: wo wird der Inhalt der EKs in diesen übertragen?

Delphi-Quellcode:

for i:=0 to componentcount-1 do
  if form.component[i] is Tedit then ...
  else
  if form.component[i] is Tradiogroup then ...
  else
  ...

Die Namen der visuellen Komponenten der Form entsprechen den Namen der Datenfelder in der Datenbank (mit einem Prefix), sodass ich mich dabei um nichts weiter kümmern muss. Nur wenn das in seltenen Ausnahmefällen nicht möglich ist, muss ich extra Code schreiben, aber in den Fällen weiss ich dann auch, dass ich besonders aufpassen muss.

Zitat:

Klar, wenn man Fehler macht, indem man gegen das eigene Programmierkonzept verstößt ...

Je mehr Dinge man manuell tun muss, desto leichter vergisst man irgendwo auf irgendwas.

Zitat:

Aber eigentlich suchst du ja tatsächlich OnChange, denn das ist genau das Ereignis, das augelöst wird, wenn der Inhalt bzw. Status einer EK verändert wird.

Eben nicht, weil ich auf das Ereignis auf der Ebene jeder einzelnen Komponente reagieren müsste. Schön wäre ein onchange der Form, aber das gibt es nicht.

Zitat:

Welche Methode verwendest du denn?

Ich verwende jetzt einen Timer, wie ich eingangs geschrieben habe.

Zitat:

Das verstehe ich jetzt nicht: Wieso ist der Button Speichern enabled, solange keine Änderungen gemacht wurden? Was gibt es davor denn zu speichern?
...
Noch mehr Verwirrung: Was versteht du unter "Buttons werden aktiviert"? Etwa Enbled := True? Der Speicherbutton ist doch bereits enabled ...

Für den User sieht es so aus:
Solange es keine Änderung gibt, gibt es einen Button "Schliessen" und der Button "abbrechen" ist disabled. Wenn etwas geändert wurde, dann wird aus dem Button "Schliessen" ein Button "Speichern" (es ist der gleiche Button mit einer anderen Caption) und der Button "Abbrechen" wird enabled. Werden alle Änderungen der Form rückgängig gemacht, sodass in der Form genau das angezeigt wird, was in der DB gespeichert ist, dann wird aus "Speichern" wieder "schliessen" und "abbrechen" wird wieder disabled.

Zitat:

Alle Eingabe-Komponenten melden doch bereits, wenn ihre Inhalt bzw. ihr Status geändert wurde. Das Ereignis heißt OnChange

Sie reagieren aber eben nicht automatisch auf die "Meldung". Dazu müsste ich neue Komponenten ableiten, die von selbst wissen, wie sie reagieren müssen, wenn onchange eintritt.

@Popov
Ja, ich fürchte, du hast Recht.

[Perlsau]

Zitat von idefix2:

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

Da hab ich mich wohl unklar ausgedrückt. Was ich wissen wollte: Gibt es eine Datenstruktur, z.B. einen Record, der die Inhalte der doch sehr unterschiedlichen Eingabe-Komponenten (EKs) aufnimmt? Wenn ja: wo wird der Inhalt der EKs in diesen übertragen? Wenn nicht: Wie speicherst du derart unterschiedliche Inhalte dieser EKs?

Zitat von idefix2:

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.

Klar, wenn man Fehler macht, indem man gegen das eigene Programmierkonzept verstößt ...

Zitat von idefix2:

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.

Welche Methode verwendest du denn? Ich hatte bislang den Eindruck, ein von dir gesuchtes Ereignis gäbe es nicht. Aber eigentlich suchst du ja tatsächlich OnChange, denn das ist genau das Ereignis, das augelöst wird, wenn der Inhalt bzw. Status einer EK verändert wird.

Weiter oben schreibst du noch etwas, was in mir den Eindruck verstärkt, dein Konzept sei zumindest noch mal zu überdenken:

Zitat von 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".

Das verstehe ich jetzt nicht: Wieso ist der Button Speichern enabled, solange keine Änderungen gemacht wurden? Was gibt es davor denn zu speichern?

Zitat von idefix2:

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.

Noch mehr Verwirrung: Was versteht du unter "Buttons werden aktiviert"? Etwa Enbled := True? Der Speicherbutton ist doch bereits enabled ...

Zitat von idefix2:

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.

Das Verlassen einer Komponente ist doch kein Garant für eine Änderung ihres Inhaltes oder ihres Status. Außer deiner Befürchtung, daß du den Fehler nicht finden würdest, gibt es keinen Grund, nicht genau das dafür vorgesehene Ereignis zu verwenden. Und keine Sorge: Den Fehler findest du schon, spätestens nach diesem Thread hier hat sich das in deinem Langzeitgedächtnis eingegraben

Zitat von idefix2:

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.

Alle Eingabe-Komponenten melden doch bereits, wenn ihre Inhalt bzw. ihr Status geändert wurde. Das Ereignis heißt OnChange. Du zäumst ein totes Pferd von hinten auf und ziehst damit die Kirche durch's Dorf, um's mal etwas überspitzt auszudrücken. Aber wie gesagt, du mußt selbst wissen, was du tust ...

[Popov]

Ich glaube du wirst nicht drumherum kommen alles selbst zu machen. Edit-Komponenten kennen zwar die Eigenschaft Modifed, aber das kennen nur die Edit-Komponenten.

Auch kennt die TForm die Eigenschaft KeyPreview. Das bedeutet, dass das Formular alle Tastaturanschläge vor dem Steuerelement erhält. Somit könnte man mit einem OnKeyDown des Formulars ein Dutzend Editfelder "überwachen". Aber es funktioniert nur bei Tastauranschlägen.