DBEdit, DBCheckBox und Co. ohne Navigator

[FediDelPr]

Ich habe DBEdit und die dazugehörige Famile von Controls bis jetzt nur
stiefmütterlich verwendet. Ich hab's immer ausprogrammiert. Da habe ich den
Vorteil der hohen Flexibilität, dafür schreibe ich mehr Code.

Manchmal ging's dann doch irgendwie einfach, aber in anderen Fällen klappte es
nicht. Ich war immer zu ungeduldig mich vertieft damit zu befassen. Jetzt scheint
es mir an der Zeit zu sein dies doch mal zu tun.

Ich sehe 2 mögliche Probleme:

- Ich habe bis jetzt noch nie den DBNavigator verwendet und werde es auch kaum tun.
Wenn schon schreibe ich einen eigenen der mir besser passt. Aber zurzeit will ich
ohne auskommen.
Der Record-Pointer wird üblicherweise über ADOQuery gesetzt. Soviel ich aus anderen
Diskussionen entnommen habe, ist das auch kein Problem solange nur auf eine Tabelle
zugegriffen wird. (Eindeutigkeit)

Im Navigator sind ja gewisse Operationen versteckt, wie z.B. Umschalten in den
Edit-Modus, das Speichern eines geänderten Records/Feldes usw.
Hier sehe ich noch nicht wirklich durch, ich muss ja in bestimmten
Momenten diese Aktionen explizit ausführen, weil ich den Navigator nicht verwende.
Sehe ich das richtig ? Gibt's irgendwo eine gute Beschreibung des DBNavigators wo
das klar wird ?

- Mir ist auch aufgefallen, dass es zu 'Schwanzbeissereien' kommen kann, z.B. wenn
ich innnerhalb DBCheckBoxChange in die Sequenz Close - Open - Edit - Post ausführe.
Kann sein, dass es da zu Konflikten kommt. Eben, es ist wichtig die Zustände genau
zu kennen und wann welche Aktionen ausführt werden müssen/darf.

Vielleicht kann man das auf einen einfachen Nenner bringen ?

Danke für Ideen und Hinweise.

[hoika]

Hallo,
tue Dir einen Gefallen, mach es wie bisher ohne die DB-Komponenten.

[haentschman]

Zitat:

mach es wie bisher ohne die DB-Komponenten

+1

Klick Bunti ist damit möglich, aber du handelst dir Probleme bei komplexen GUI´s ein.

Zitat:

Mir ist auch aufgefallen, dass es zu 'Schwanzbeissereien' kommen kann, z.B. wenn
ich innnerhalb DBCheckBoxChange in die Sequenz Close - Open - Edit - Post ausführe

...sowas z.B.

[jobo]

Dein Problem ist nicht so recht klar.

Nimm Dir ein Grid, eine Query, eine Datasource und ein Navigator und füge sie zusammen und schreibe ein editierbares SQL Statement für die Query und starte das Programm.
Ohne den Navigator überhaupt zu klicken, kannst Du bei einer Arbeit mit dem Grid feststellen, dass er einfach schonmal den Zustand des Dataset / Query reflektiert. Dabei stört er handgeklöpelten Code in keiner Weise.
Und klar, Ereignis getriebener Code kann schief gehen, wenn er zu recursiven Aufrufen führt. Auch dazu trägt der Navigator nicht selbst bei.

Und wegen roter Box:
Ich denke im Unterschied zu meinen Vorrednern, es ist schon legitim, mit Delphi das einzusetzen, womit es antritt. Und RAD ist vielleicht doch was anderes, als jedes Pixel selbst zu malen usw.
Und egal welches Sprache man nimmt, das erste was passiert, es entstehen frameworks, die "alles etwas einfacher machen" und die dann in der 3. Generation diesen Ansatz aus den augen verlieren.

Zuletzt war es ja schließlich Deine Frage, wie es denn nun geht. Am besten, Du lieferst ein konkretes Beispiel, was bei Dir hakt.

[Delphi.Narium]

Programmiere seit 1995 mit Delphi. Nutze seit dem regelmäßig DBGrid, DBNavigator und Co.. Hatte noch nicht einmal Probleme damit. Das funktioniert schlicht und einfach quer durch alle mir bekannten Delphiversionen hindurch.

Wer allerdings sowas macht

Zitat von FediDelPr:

Mir ist auch aufgefallen, dass es zu 'Schwanzbeissereien' kommen kann, z.B. wenn
ich innnerhalb DBCheckBoxChange in die Sequenz Close - Open - Edit - Post ausführe

gehört, meiner Meinung nach, verprügelt.

Wie bitteschön kann man auf die Idee kommen, ein Datenbankfeld zu verändern und dabei gleichzeitig die Datenmenge, zu der dieses Datenbankfeld gehört und dessen Inhalt gerade verändert werden soll, schließen, neu öffnen, editieren und speichern?

Aus welch edlem Grunde soll das denn so in dieser Art überhaupt funktionieren?
Man zieht also einer datensensitiven Komponente, während man mit ihrer Hilfe Daten verändert, die Datenmenge unterm Hinter weg, schiebt ihr 'ne neuen Datenmenge unter und erwartet, dass dann beim Ändern und Speichern das gewünschte herauskommt Sorry, aber dafür fehlt mir nun jedes Verständnis.

Und dieses Vorgehen wird auch beim Verzicht auf datensensitive Komponenten und den vollständigen Wechsel zu Objekten (egal wie auch immer sie im Detail gestaltet sein mögen), nicht funktionieren.

Man kann kein Objekt ändern, es während der Änderung wegwerfen und durch ein neues ersetzen und dann erwarten, dass die im ursprünglichen Objekt gemachten Änderungen auch dort "ankommen".

Das ist kein Problem der datensensitiven Komponenten, sondern ein Designproblem.