Windows Message bei Änderung?

**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?

markieren

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.

Alle Ereignisse werden automatisch ausgelöst, wenn ihre Bedingung zutrifft. OnChange reagiert auf alle Benutzer-Eingaben automatisch - zumindest in meinem Delphi 2009. Vielleicht ist das ja bei dir anders ...

Wieso verwendest du nicht einfach DB-sensitive Komponenten, wenn bereits deine Eingabe-Felder direkt mit Datenbank-Feldern korrespondieren?

Aber egal, du mußt nicht antworten, ich geb's hier sowieso auf und überlasse dich deinen – aus meiner Sicht – merkwürdigen Programmierkonzepten

**idefix2**

Zitat von Perlsau:

OnChange reagiert auf alle Benutzer-Eingaben automatisch - zumindest in meinem Delphi 2009. Vielleicht ist das ja bei dir anders ...

OnChange tut erst einmal gar nichts, solange du nicht explizit ein OnChange-Ereignis programmierst und das im OI (oder sonstwie) der Komponente zuweist.
Ich glaube nicht, dass das bei dir anders ist.

Zitat von Perlsau:

Aber egal, du mußt nicht antworten, ich geb's hier sowieso auf und überlasse dich deinen – aus meiner Sicht – merkwürdigen Programmierkonzepten

Stimmt, man muss nicht immer alles verstehen

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

[EDIT]
Ich benutze sowas in der Art:

zusammenfalten · markieren

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;

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

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

markieren

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:

markieren

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:

markieren

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.

Irgendwie hab ich den Eindruck, dir ist die Arbeitsweise eines Delphi-Programms nicht so recht klar ... mein ganz persönlicher subjektiver Eindruck, den mußt du ja nicht teilen und solltest dich auch nicht darüber ärgern, daß ich das so sehe, wie auch ich mich nicht darüber ärgere, daß du dir Umstände machst, wo das nicht wirklich notwendig wäre.

Zitat von idefix2:

Zitat von Perlsau:

OnChange reagiert auf alle Benutzer-Eingaben automatisch - zumindest in meinem Delphi 2009. Vielleicht ist das ja bei dir anders ...

OnChange tut erst einmal gar nichts, solange du nicht explizit ein OnChange-Ereignis programmierst und das im OI (oder sonstwie) der Komponente zuweist.
Ich glaube nicht, dass das bei dir anders ist.

Eigentlich wollte ich hier ja nichts mehr posten, aber du provozierst das, indem du den Sinn meiner Aussage so verdrehst, als hätte ich behauptet, die Zuweisung eines Ereignisses würde auch gleich die Ereignisbehandlung erstellen oder beinhalten. Tatsächlich habe ich geschrieben, daß Ereignisse immer automatisch ausgelöst werden – ausgelöst und nicht behandelt –, und zwar auf deine falsche Behauptung hin, daß Ereignisse nicht automatisch ausgelöst würden.

Letztendlich mußt du auch bei deiner "Lösung" eine Ereignisbehandlung schreiben, denn das Timer-Ereignis tut auch erstmal gar nichts außer eben auszulösen. Oder mit anderen Worten: Der Kampf gegen Windmühlen war schon immer ein aussichtsloser

Ich denke, du solltest das so machen, wie du denkst, und auf keinen Fall dumme Ratschläge von erfahrenen Programmieren annehmen, ja nicht einmal darüber nachdenken, warum die überhaupt was vorschlagen ... um vielleicht zu einem späteren Zeitpunkt den Holzweg, auf den du dich – meiner bescheidenen subjektiven Ansicht nach – begeben hast, erkennen zu können. Macht ja nix, ich muß ja deinen Code weder warten noch erweitern und auch nicht mit deiner Anwendung arbeiten

Aber ich kann mich noch gut daran erinnern, daß ich früher – heute etwas weniger – zahlreiche umständliche Klimmzüge veranstaltet habe, weil mir so manche Funktion von Delphi einfach noch nicht bekannt oder ich falsch darüber informiert war, wie sie funktioniert. Wenn man dann gleichzeitig an den eigenen Mythos vom gewieften Programmierer glauben will oder muß, hat man da ein echtes Problem am (oder im) Hals

Achso, bevor ich's vergesse: Mich würde noch immer interessieren, wieso du keine datensensitiven Komponenten verwendest, wenn du schon mit einer Datenbank arbeitest und die Komponenten doch, wie du schriebst, direkt mit diversen DB-Feldern assoziiert sind. Da würden nämlich alle Änderungen sofort ohne Timer oder OnChange-Ereignisbehandlung gespeichert werden. Ob ich das noch erfahren werde in diesem Leben? Ach was soll's, das Leben geht weiter

Ich habe heute auf jeden Fall eines gelernt: OnChange ist für manche Programmierer ganz ganz böse

In Wirklichkeit hab ich natürlich was ganz anderes gelernt ... aber du mußt ja nicht alles wissen

**idefix2**

Zitat von Popov:

Übrigens, wie soll WinControl wissen ob es eine Änderung in ihr gab? Ist eine Texteingabe in TEdit eine Änderung? Klar. Ist das Setzen der CheckBox eine Änderung? Klar. Ist das Bewegen des Mauszeigers von rechts nach links über ein Panel eine Änderung? In Smartphones ist das eine Funktion.

Nachdem es die Message nicht gibt, sind weitere Überlegungen in die Richtung natürlich sinnlos. Aber wenn es so eine Message geben würde, dann müsste natürlich jede Komponente selbst wissen, wann sie sie verschicken muss, TWinControl kann das nicht. Das könnte mir aber gleichgültig sein.