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.