Windows Message bei Änderung?

[Popov]

Ich habe mich gerade an meine Routine für Faule erinnert. Damals habe ich just4fun eine Funktion geschrieben mit der es möglich war alle Einstellungen auf dem Formular in eine Ini zu speichern/daraus zu laden, ohne die einzelnen Komponenten in eine Speiche- oder Ladeliste eintragen zu müssen. Ich hab einfach alles gespeichert und geladen.

Die Routine finde ich jetzt nicht mehr, aber das Prinzip ist einfach und evtl. auf dein Problem anwendbar. In einer Durchgang wird aus allen Inhalten aller Komponenten auf dem Formular eine Checksumme gebildet. Unterscheidet sie sich zu der vorherigen, gibt es eine Änderung.

Das spezielle an der Routine ist, dass in die Routine nur einmal der Komponententyp aufgenommen werden muss, z. B. TEdit. Danach werden automatisch alle TEdits erfasst, auch solche die neu dazukommen.

Ich hab das hier mit einer Checksumme gemacht, man kann es auch anders machen. Wichtig ist nur, dass so alle Komponenten überprüft werden.

Delphi-Quellcode:

function ChecksumStr(s: string): Integer;
begin
  Result := -1; //Hier aus einem String eine Checksumme bilden
end;

function ChecksumInt(i: Integer): Integer;
begin
  Result := -1; //Hier aus einem Integer eine Checksumme bilden
end;

function ChecksumBool(b: Boolean): Integer;
begin
  Result := -1; //Hier aus einem Boolean eine Checksumme bilden
end;

procedure TForm1.Button2Click(Sender: TObject);
var
  i, ChkSum: Integer;
begin
  ChkSum := 0;

  for i := 0 to ComponentCount - 1 do
  begin
    if Components[i].ClassType = TEdit then
      ChkSum := ChkSum + ChecksumStr(TEdit(Components[i]).Text);

    if Components[i].ClassType = TComboBox then
      ChkSum := ChkSum + ChecksumInt(TComboBox(Components[i]).ItemIndex);

    if Components[i].ClassType = TCheckBox then
      ChkSum := ChkSum + ChecksumBool(TCheckBox(Components[i]).Checked);

    if Components[i].ClassType = TRadioButton then
      ChkSum := ChkSum + ChecksumBool(TRadioButton(Components[i]).Checked);
  end;

  //Hier dann die CheckSumme auf Änderung prüfen
  ShowMessage(IntToStr(ChkSum));
end;

Achso, die Funktionen für Checksummen müssten selbst programmiert werden.

[idefix2]

Genau nach diesem Prinzip arbeitet meine Routine zum Erkennen einer Änderung.
Wenn die Daten in das Formular geladen werden, werden die Werte aller Komponenten des Formulars in so einer Schleife durchlaufen und in einer Stringlist abgelegt.
Die Routine, die auf Änderungen prüft, vergleicht die aktuellen Werte der Controls mit denen in der Liste.

[Popov]

Wie gesagt, hier werden nicht alle Komponenten in eine Liste eingetragen, nur die Klassen-Typen.

Aber um auf dein Problem nochmal einzugehen, wenn man kompliziert genug denkt und noch komplizierter programmiert, könnte man vielleicht etwas fabrizieren. Das Ergebnis wäre eine komplexe Routine. Am Ende würde man sich aber fragen wieso man nicht einfach bei jeder Komponente in der OnChange Prozedur ein globales Modifed auf True gesetzt hat.

Aber ich möchte noch mal zu meiner Geschichte mit den Flugzeugen zurück kommen. Bist du sicher sie verstanden zu haben? Da geht es drum sich in einer Idee zu verlieren ohne den Blick für andere Lösungen zu haben.

In deinem Fall stellt sich die Frage ob es wirklich nötig ist, dass der Speichern Button erst bei einer Änderung aktiv wird. Wäre es schlimm wenn der Button immer Aktiv wäre? Und wenn es wichtig ist, ist die Anzahl der Komponenten so groß, dass es zu aufwändig ist bei jeder Komponente zu reagieren und ein Modifed-Wert zu setzten?

Ansonsten empfehle ich dir das Demo Programm (Delphi-Ordner) ReichEdit anzugucken. Da wird auch viel auf Änderungen reagiert. Guckt mir mal an wie die mit Modifed umgehen.

[idefix2]

Zitat von Popov:

In deinem Fall stellt sich die Frage ob es wirklich nötig ist, dass der Speichern Button erst bei einer Änderung aktiv wird. Wäre es schlimm wenn der Button immer Aktiv wäre? Und wenn es wichtig ist, ist die Anzahl der Komponenten so groß, dass es zu aufwändig ist bei jeder Komponente zu reagieren und ein Modifed-Wert zu setzten?

Was ist schon NÖTIG, und was ist WICHTIG?
Das User-Interface gewinnt durch diese Feature sicher ein wenig an Attraktivität, unbedingt nötig wäre es natürlich nicht.
Es geht nicht darum, ob es zu aufwändig wäre, bei jeder Komponente zu reagieren, sondern darum, dass alles, was man routinemässig manuell irgendwo eintragen muss, eine potentielle zukünftige Fehlerquelle ist. Und besonders lästig sind Fehlerquellen dann, wenn sie beim Testen des Programms nicht zwangsläufig sofort auffallen, sondern wenn dann erst nach Auslieferung an den Kunden eine Reklamation kommt. Dann erweist sich der ursprüngliche Gewinn für das User-Interface nämlich als Eigentor.
Deshalb würde ich auf die Feature (die ich durchaus als Gewinn ansehe) eher verzichten und den Speichern Knopf immer aktiv lassen, wenn es nicht Möglichkeiten geben würde, sicherzustellen, dass auch bei zukünftigen Programmänderungen in dem Bereich keine (unnötigen) Fehler entstehen können, weil der Programmierer, der die Änderungen macht (ich selbst oder ein Mitarbeiter) übersieht, dass bei jedem neuen Control die OnChange Routine zugeordnet werden muss, weil sonst die Aktivierung des Speichern-Buttons nicht mehr richtig funktioniert. Wenn ich nach drei Jahren an dem Programm eine kleine Änderung machen soll, denke ich unter Umständen selbst auch nicht mehr daran, und schon gar nicht, wenn ich einen Mitarbeiter mit der Trivialaufgabe betraue, er soll in ein Formular der Anwendung zwei neue Datenfelder einbauen.