Edit oder DBedit?

[Hansa]

Sharky hat offensichtlich dieselben Erfahrungen mit DB-Komponentanen gemacht wie ich. Zumindest bei mir sind sie ziemlich schnell an ihre Grenzen gestoßen. Die sind ganz einfach zu starr. 3 Beispiele :

DBGrid :

ich brauche manchmal bei Artikeln 2 Zeilen für die Bezeichnung. Die sollen untereinander stehen, nicht nebeneinander. Das betrifft aber nur eine Spalte. Es ging einfach nicht wie gewünscht. Besser gesagt, habe ich es nach 2 Wochen Handbuch lesten, testen usw. aufgegeben. In einem Tag habe ich es mit einem Stringgrid hingekriegt. DBCtrlGrid war auch nicht zufriedenstellend.

DBComboBox :

Hier war die Anforderung, daß die Auswahl auch durch Eingabe der Nr. möglich sein sollte. Ich bekam die Nr. und die Bezeichnung zwar in die Box, nicht aber in das Auswahlfeld, damit war allerdings nach 1 Tag schon Schluß.

TDBchart :

dem habe ich gerade mal eine Stunde gegeben, um eine gute Dasrtellung zu präsentieren. Ging nicht. Mit TChart ging es aber in der Zeit.

Eine Ausnahme stellt in dem Projekt allerdings das DBEdit und DBText dar. Die verwende ich schon. Sind ja auch die einfachsten von allen. Aber die wiederum sind zu einfach. Deshalb habe ich sie erweitert. Ich habe also ein DBIntEdit, DBRealEdit usw. und wenn ich die auf die Form lege, dann ist schon mal geklärt, daß nur Zahlen oder auch nur ein Komma usw. eingegeben werden können. Der Nachteil hierbei war, daß man für so was schon tief in die Komponentenentwicklung einsteigen muß. Aber es war ziemlich klar, daß man da nicht komplett drumrum kommt.

Und noch eines zum Schluß : das "Allheilmittel" Fremdkomponenten. Habe mir da auch welche angesehen. Die waren zwar besser als die Standard-Delphi Sachen, aber immer noch nicht so gut, daß es sich gelohnt hätte dafür Geld zu investieren, denn wenn die 40% der abgedeckten Anforderungen von Delphi schon zu wenig sind, dann sind die 80% einer Fremdkomponente eben immer noch zu wenig.

[GuenterS]

Ich habe mal eine Anwendung ziemlich schnell entwickeln müssen und es wurde darauf gedrängt, dass ich die DB Editoren verwende.

Das hat sich aber schlußendlich als ein Schuss nach hinten herausgestellt, da man wirklich vieles nicht mehr kontrollieren kann. So zum Beispiel passiert ein implizites post wenn Du in einer DBLookupbox den Eintrag wechselst.

[GuenterS]

Zitat von Hansa:

Eine Ausnahme stellt in dem Projekt allerdings das DBEdit und DBText dar. Die verwende ich schon. Sind ja auch die einfachsten von allen. Aber die wiederum sind zu einfach. Deshalb habe ich sie erweitert. Ich habe also ein DBIntEdit, DBRealEdit usw. und wenn ich die auf die Form lege, dann ist schon mal geklärt, daß nur Zahlen oder auch nur ein Komma usw. eingegeben werden können. Der Nachteil hierbei war, daß man für so was schon tief in die Komponentenentwicklung einsteigen muß. Aber es war ziemlich klar, daß man da nicht komplett drumrum kommt.

Und noch eines zum Schluß : das "Allheilmittel" Fremdkomponenten. Habe mir da auch welche angesehen. Die waren zwar besser als die Standard-Delphi Sachen, aber immer noch nicht so gut, daß es sich gelohnt hätte dafür Geld zu investieren, denn wenn die 40% der abgedeckten Anforderungen von Delphi schon zu wenig sind, dann sind die 80% einer Fremdkomponente eben immer noch zu wenig.

DBEdit prüft doch eigentlich eh schon was für ein Datenfeld dahinter steckt, also kann man in ein Zahlenfeld eh auch keine Strings eingeben (außer Hexzahlen).

Es gibt schon auch gute (teure) Fremdkomponenten, wenn ich da an das QuantumGrid von DevExpress denke. Tabellen inherhalb anderer Tabellen bis zur x-ten Ebene, mit Gruppier und Sortiermöglichkeit, eingebauten Filtern, etc. Da würde man schon lange brauchen um das selber in der Art zu programmieren.

[Bernhard Geyer]

Zitat von GuenterS:

Es gibt schon auch gute (teure) Fremdkomponenten, wenn ich da an das QuantumGrid von DevExpress denke. Tabellen inherhalb anderer Tabellen bis zur x-ten Ebene, mit Gruppier und Sortiermöglichkeit, eingebauten Filtern, etc. Da würde man schon lange brauchen um das selber in der Art zu programmieren.

Zur reinen Darstellung mag das einen Vorteil bringen. Aber wenn es ins Detail geht ist man ohne DB-Bindung besser dran.

[Schuster]

Also ich muß allen zustimmen die ein reines Editfeld nehmen denn
ich hab nur ein kleines DB Projekt und bin auch schon auf die grenzen
eine DB-Editfeldes gestoßen.

Ist zwar mehr arbeit, da alles manuel befüllt werden muß aber man
hat eben die voll Kontrolle.

[Hansa]

Zitat von GuenterS:

DBEdit prüft doch eigentlich eh schon was für ein Datenfeld dahinter steckt, also kann man in ein Zahlenfeld eh auch keine Strings eingeben (außer Hexzahlen).

Es gibt ja noch viel mehr. Rechtsbündige Zahlendarstellung wie bei Taschenrechner ? Label gleich mit dabei ? 2 Kommas unterbinden, Tausender-Trennzeichen ? usw. Geht das mit Standard DB-Edits ? Hex geht sogar ? Bei mir leider nicht. Da ich so was auch brauche für nicht-DB Komponenten habe ich kurzerhand eben das für DBEdits gleich mit übernommen und somit einheitlich gemacht.

Aber wie gesagt, das sind eigene Komponenten und die kann man nicht einfach so nebenbei in 5 Min. ohne Vorkenntnisse schnell machen. Basieren tun sie aber tatsächlich auf dem Standard DBEdit.

[GuenterS]

Zitat von Bernhard Geyer:

Zitat von GuenterS:

Es gibt schon auch gute (teure) Fremdkomponenten, wenn ich da an das QuantumGrid von DevExpress denke. Tabellen inherhalb anderer Tabellen bis zur x-ten Ebene, mit Gruppier und Sortiermöglichkeit, eingebauten Filtern, etc. Da würde man schon lange brauchen um das selber in der Art zu programmieren.

Zur reinen Darstellung mag das einen Vorteil bringen. Aber wenn es ins Detail geht ist man ohne DB-Bindung besser dran.

Du scheinst diese Fremdkomponente nicht zu kennen, sonst würdest mir zustimmen. Aber es gibt von allem gut und böse bzw. schlecht.

[plautzer]

HI leute,

ich habe noch mal ein paar fragen zu StringGrids und Dbgrids.

DAs grid soll mit abrechnungsdaten gefüllt werden, also nichts kompliziertes.
Es soll nur bei erstellen eines neuen datensatzes, 2 daten automatisch eingefügt werden (IDs).

Das habe ich bis jetzt alles mit StoredProcs gelöst. Kann ich diese auch in Verbindung mit dbgrids verwenden, oder sollte man da eher ibdatasets verwenden?

Ich nehme an, das es ziehmlich kompliziert und aufwendig ist mit einen Stringgrid zu arbeiten (d.h. daten hinzufügen, aktualisieren und löschen).

Welche erfahrung habt ihr bisher gemacht?

Plautzer

[Hansa]

Zitat von plautzer:

...Das habe ich bis jetzt alles mit StoredProcs gelöst. Kann ich diese auch in Verbindung mit dbgrids verwenden, oder sollte man da eher ibdatasets verwenden?
...

Plautzer was soll das ? Du vermischst visuelle Delphi-Komponenten mit Sachen der DB. 8)