Windows Message bei Änderung?

[Dalai]

Zitat:

Zitat von Captnemo (Beitrag 1301956)

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 :).

[idefix2]

Zitat:

Zitat von Captnemo (Beitrag 1301955)

Zitat:

Zitat von idefix2 (Beitrag 1301952)

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.

Genau der Satz, den du von mir zitiert hast, spricht dagegen. Ein falsche Ausrichtung des Controls sehe ich auf den ersten Blick, wenn ich die Form öffne. Schon eine falsche Tab-Reihenfolge eines irgendwo in der Mitte eingefügten Eingabefelds ist für den User mühsam und passiert immer wieder, wenn der Programmierer beim Testen des Programms vorwiegend mit der Maus arbeitet. Und dass die Zuordnung von onchange vergessen worden ist, kann beim Testen des Programms noch leichter übersehen werden als eine falsche Tab-Reihenfolge.

[Jumpy]

Zitat:

Zitat von idefix2 (Beitrag 1301957)

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

Zitat:

Zitat von Dalai (Beitrag 1301948)

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:

Zitat von Jumpy (Beitrag 1301966)

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:

Zitat von Jumpy (Beitrag 1301966)

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.

[Captnemo]

Zitat:

Zitat von idefix2 (Beitrag 1301959)

Zitat:

Zitat von Captnemo (Beitrag 1301955)

Zitat:

Zitat von idefix2 (Beitrag 1301952)

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.

Genau der Satz, den du von mir zitiert hast, spricht dagegen.

Aha. Dann verneige ich mich ehrfürchtig und bin raus.

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

Zitat von Popov (Beitrag 1301984)

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.