TObjectList reagiert nicht auf ModifyAction

[Uwe Raabe]

Zitat von RWarnecke:

Normal sollte das Setzen von lnChange auf die Eigenschaft ModifyAction die procedure getItem aufrufen,

Wieso? Das Property ModifyAction hat als Setter lediglich das entsprechende Feld FModifyAction angegeben. Ein Schreiben auf das Property kann damit eigentlich gar nichts auslösen (zumindest nicht direkt). Ich behaupte auch mal, daß das unter D2007 nicht anders ist.

Wobei ich mir hier nebenbei die Frage stelle, warum das Setzen des Properties ModifyAction überhaupt getItem aufrufen sollte...

Ansonsten kann ich mich nur stahli anschließen: Ich denke, Du müsstest mal etwas mehr zeigen.

[stahli]

Es soll vermutlich den Modus umstellen, ähnlich wie bei TTable.Insert ... TTable.Post.
Ich denke auch, dass die Bezeichnungen nicht ganz schlüssig bzw. erst mal (im ersten Moment) etwas irreführend sind.

[RWarnecke]

Hallo zusammen,

danke erstmal für Eure Antworten. Ich habe den Fehler gefunden. Diese zwei folgenden Zeilen haben in den Set-Proceduren von TAnsprechpartnerListe gefehlt :

Delphi-Quellcode:

  if (Assigned(FOnChange)) and (FModifyAction = lnChange) then
    FOnChange(Self, Self);

Damit funktioniert jetzt alles so wie es soll. Eine vollständige Set-Procedure von TAnsprechpartnerListe sieht dann jetzt so aus :

Delphi-Quellcode:

procedure TAnsprechpartnerListe.SetMobil(Value: string);
begin
  FMobil := Value;
  if (Assigned(FOnChange)) and (FModifyAction = lnChange) then
    FOnChange(Self, Self);
end;

Wenn ich jetzt im Programm auf eine Änderung in einem Eingabefeld reagieren sieht das ganze so aus :

Delphi-Quellcode:

    with TAnsprechpartnerListe(AnsprechpartnerListe.Items[AdvLV_CustomerContacts.Selected.Index]) do
    begin
      ModifyAction := lnChange;
      KundenNr := TKundenListe(KundenListe.Items[MainForm.AdvLV_OverviewList.Selected.Index]).KundenNr;
      Vorname  := CustomerContact.AdvEdt_CustomerContactsVorname.Text;
      Nachname := CustomerContact.AdvEdt_CustomerContactsNachname.Text;
      Telefon1 := CustomerContact.AdvEdt_CustomerContactsTelefon1.Text;
      Telefon2 := CustomerContact.AdvEdt_CustomerContactsTelefon2.Text;
      Fax      := CustomerContact.AdvEdt_CustomerContactsFax.Text;
      Mobil    := CustomerContact.AdvEdt_CustomerContactsMobil.Text;
      EMail    := CustomerContact.AdvEdt_CustomerContactsEMail.Text;
      ModifyAction := lnNone;
    end;

Damit werden dann alle Änderungen in die Datenbank geschrieben.

Edit: Rechtschreibfehler korrigiert.

[stahli]

Mal zwei Nachfragem zum grundsätzlichen Konzept:

Du nutzt eine Datenbank? Warum keine DB-Komponenten?

Dann überträgst Du mehrere ...Edit.Text händisch in zugehörige Objekteigenschaften.
Hast Du Dir schon einmal data binding angesehen, ob das etwas für Dich wäre?
Je nachdem, wie weit Du mit Deinem Projekt bist, könnte Dir so etwas evtl. die weitere Arbeit erleichtern...

[RWarnecke]

Zitat von stahli:

Du nutzt eine Datenbank?

Ja,ich nutze eine Firebird-Datenbank.

Zitat von stahli:

Warum keine DB-Komponenten?

Ich nutze deshalb keine DB-Komponenten, weil ich zum einen mit den Dingern nie richtig zurechtgekommen bin und zweitens habe ich im Moment in meinem Projekt lediglich nur zwei Units, die ich anpacken müsste, wenn denn mal eine andere Datenbank-Komponente zum Einsatz kommen müsste. Zum Beispiel, ich will mein Programm auch noch für ein anderes DBMS zugänglich machen.

Zitat von stahli:

Dann überträgst Du mehrere ...Edit.Text händisch in zugehörige Objekteigenschaften.
Hast Du Dir schon einmal data binding angesehen, ob das etwas für Dich wäre?
Je nachdem, wie weit Du mit Deinem Projekt bist, könnte Dir so etwas evtl. die weitere Arbeit erleichtern...

Mein Projekt ist noch nicht soweit. Habe bis jetzt lediglich die Kundenverwaltung angefangen.

[Stevie]

Muss dein Programmcode abwärtskompatibel (< Delphi 2010) sein? Wenn nicht, dann würde ich empfehlen, dich mal mit Generics zu beschäftigen, und die TObjectList<TAnsprechpartner> zu nutzen.

Wenn ich mir den Source Ausschnitt anschaue, entstehen bei mir auch die Fragen, warum in der Datenobjekt Klasse ein Event steht, was in der Liste enthalten sein sollte. Diese sollte nämlich mitbekommen, wenn ein Element hinzukommt, oder rausgenommen wird. Dies ist übrigens auch in sowohl TObjectList, als auch TObjectList<T> enthalten. Für die Benachrichtigung, wenn ein Wert innerhalb des Datenobjekts verändert wurde, solltest du einen anderen Eventtyp implementieren. Solltest du dich für die Databinding Lösung entscheiden, gibt es dort eine entsprechende Basisklasse, die diese Funktionalität implementiert.

Wenn dein Programm noch am Anfang der Entwicklung steht, würde ich dir auch nahelegen, dich mit dem Data Binding Thema zu beschäftigen, denn es klingt gerade zu nach dem prädestinierten Anwendungsgebiet dafür. Falls du Fragen hast und/oder Hilfe brauchst, stehen dir ja einige Wege offen, mich zu erreichen.

[RWarnecke]

Hallo Stefan,

Zitat von Stevie:

Muss dein Programmcode abwärtskompatibel (< Delphi 2010) sein?

Nein,mein Programmcode muss nicht abwärtskompatibel sein.

Zitat von Stevie:

Wenn nicht, dann würde ich empfehlen, dich mal mit Generics zu beschäftigen, und die TObjectList<TAnsprechpartner> zu nutzen.

In wie weit erleichtern die mir die Arbeit ?

Zitat von Stevie:

Wenn ich mir den Source Ausschnitt anschaue, entstehen bei mir auch die Fragen, warum in der Datenobjekt Klasse ein Event steht, was in der Liste enthalten sein sollte. Diese sollte nämlich mitbekommen, wenn ein Element hinzukommt, oder rausgenommen wird. Dies ist übrigens auch in sowohl TObjectList, als auch TObjectList<T> enthalten. Für die Benachrichtigung, wenn ein Wert innerhalb des Datenobjekts verändert wurde, solltest du einen anderen Eventtyp implementieren. Solltest du dich für die Databinding Lösung entscheiden, gibt es dort eine entsprechende Basisklasse, die diese Funktionalität implementiert.

Ich habe damals nach einer Möglichkeit gesucht, die Datenbank-Abfragen vom eigentlichen Programmcode zu trennen. Da bin ich auf die TObjectList mit einer Klasse gekommen und habe mir dieses Konstrukt zusammengebaut, welches auch recht zuverlässig funktioniert. Ich bin natürlich für neue Ideen offen, die mir das Leben noch erleichtern.

Zitat von Stevie:

Wenn dein Programm noch am Anfang der Entwicklung steht, würde ich dir auch nahelegen, dich mit dem Data Binding Thema zu beschäftigen, denn es klingt gerade zu nach dem prädestinierten Anwendungsgebiet dafür. Falls du Fragen hast und/oder Hilfe brauchst, stehen dir ja einige Wege offen, mich zu erreichen.

Mein Programm steht noch am Anfang der Entwicklung. Ich habe gerade mal die Kundenverwaltung fertig. Ich schaue mir schon Dein Projekt Data Bindings an. Danke schon mal für Dein Hilfeangebot. Wenn ich irgendwas nicht verstehe, werde ich gerne darauf zurückkommen.

[sx2008]

Zitat von RWarnecke:

Ich habe den Fehler gefunden.

Aber dein Klassendesign bleibt weiterhin fehlerhaft.
Es fängt schon an beim falschen Klassennamen.
(Niemand würde auf die Idee kommen die Klasse TFont als TFontList zu bezeichen;
genau darf doch ein Klasse, die Daten zu einem Ansprechpartner nicht TAnsprechpartnerList heisen)
Das Property ModifyAction gehört nicht zum einzelnen Ansprechpartner-Objekt;
aber das habe ich ja schon in Betrag #3 erklärt.

[RWarnecke]

Zitat von sx2008:

Zitat von RWarnecke:

Ich habe den Fehler gefunden.

Aber dein Klassendesign bleibt weiterhin fehlerhaft.
Es fängt schon an beim falschen Klassennamen.
(Niemand würde auf die Idee kommen die Klasse TFont als TFontList zu bezeichen;
genau darf doch ein Klasse, die Daten zu einem Ansprechpartner nicht TAnsprechpartnerList heisen)

Namen sind doch wie Schall und Rauch. Da ich alleine Programmiere, reichen mir die Namen so wie Sie sind. Deshalb habe ich ja die zweite Klasse auch noch mit einem Obj versehen, damit weiß ich dann, welches meine Klasse ist und welche meine TObjectlist ist.

Zitat von sx2008:

Das Property ModifyAction gehört nicht zum einzelnen Ansprechpartner-Objekt;
aber das habe ich ja schon in Betrag #3 erklärt.

Wenn ich aber die Property ModifyAction beim einzelnen Ansprechpartner-Objekt rausnehme funktioniert mein Aufruf wie in Beitrag #6 geschrieben nichtmehr.

[Stevie]

Zitat von RWarnecke:

Namen sind doch wie Schall und Rauch. Da ich alleine Programmiere, reichen mir die Namen so wie Sie sind. Deshalb habe ich ja die zweite Klasse auch noch mit einem Obj versehen, damit weiß ich dann, welches meine Klasse ist und welche meine TObjectlist ist.

Mag in gewissem Sinne stimmen und kannst du gerne so machen, wie du meinst. Dennoch: Wenn ich meine Jacke Hose nenne und meine Schuhe Hemd... würd ich dann nicht sobald ich mit anderen in Kontakt komme als ein bisschen banane angesehen werden, wenn ich zu Besuch komme und frage, wo ich meine Hose aufhängen kann und ob ich mein Hemd anlassen kann?