Was ist eure "Most brainfucking Delphi component ever?"

**Codehunter**

Hallo!

Nachdem ich die letzten drei Tage viele viele Stunden mit lustigem Property-Suchen verbracht habe, bin ich inzwischen kurz vorm Burnout

Vor einigen Jahren, als ich mit VirtualTreeview anfing, ich erinnere mich noch gut, war das meine "Most brainfucking Delphi component ever". Doch hatte ich das Funktionsprinzip erstmal verstanden, wars kein Problem mehr.

Heute bin ich wieder genau an dem selben Punkt, nur mit dem TcxGrid von DevExpress. Selbst für so simple Aufgaben wie den ColIndex und RowIndex der fokussierten Zelle rauszufinden, sucht man sich dumm und fusselig. Vorallem, weil die verfügbaren Codesamples von DevExpress entweder völlig veraltet sind oder durch das exzessive Typcasting innerhalb dieser Komponente auf verschiedene Property-Subklassen (Views, Controller, ColumnProperties etc.) mit wiederum unterschiedlichen Properties verweisen.

Gemessen an TcxGrid ist der VirtualTreeview geradezu elegant. Für ersteres fällt mir nur noch eines ein: Völlig overengineered.

Darum dachte ich mir, ich frag einfach mal, was denn eure "Most brainfucking Delphi component ever" ist. Vielleicht machen wir am Ende eine Abstimmung?

Grüße
Cody

**dummzeuch**

Oh ja, das kenne ich: Wie TVirtualTreeView funktioniert vergesse ich ständig und muss es mir jedes Mal neu erarbeiten. Zumal es in verschiedenen Programmen für unterschiedliche Features verwendet und deshalb jedesmal anders benutzt wird.

Das hat in mir eine Abneigung dagegen erzeugt, es überhaupt zu verwenden, wenn ich es irgendwie vermeiden kann, obwohl es wirklich eine mächtige Komponente ist.

TcxGrid kenne ich nur dem Namen nach.

Ich würde allerdings TXmlDocument nominieren. Durch die Verbindung von Komponente und (COM-)Interfaces gibt es immer wieder mal seltsame Effekte, in der Regel mit unbrauchbaren Fehlermeldungen, gerne mal in einem Hintergrund-Thread, die man stundenlang debuggen kann.

**freejay**

Ich finde auch die beiden genannten am schlimmsten, wobei TXMLDocument die Liste mit Abstand anführt...

PS: Ich verwende ja das TAdvStringGrid von TMS und obwohl die TMS-Komponenten schon auch ein historisch gewachsener Wust von Vorgehensweisen, Schreibweisen etc. sind: Dort wären die beiden gesuchten Werte einfach Col und Row

**Rollo62**

Zitat von Codehunter:

Gemessen an TcxGrid ist der VirtualTreeview geradezu elegant. Für ersteres fällt mir nur noch eines ein: Völlig overengineered.

Ja da bin ich ganz bei Dir.
Deshalb lege ich mir für viele Komponenten einen interposer an, und erweitere einfach die "Basisfunktionen",
wie ich sie erwarten würde.

Z.B. gibt es bei den Grids oft auch kein "Clear;", warum nicht ?! Arbeiten diese Leute nicht selbst damit ?

Gerne nehme ich auch dafür Helper, die aber leider nicht immer ausreichen wenn man an die Interna muss.
Weil die interposer auch sehr zuverlässig funktionieren mache ich mir da keinen Kopf.

Die zusätzlichen Vorteile:
- Interface: Ich definiere quasi mein eigenes, parallel nutzbares API, was ich dann auch für mich "kompatibel" halten kann.
- Nomenklatur: Das heisst in meinem Interface gibt es immer "Items", und nicht mal "Elements", "Lines" oder sonstwas.
- In meinem Interface gibt es in der Regel auch TryGet/TrySet/...-Funktionen,
um die Zugriffe ohne zusätzlichen Guard-Code abzusichern.
- In meinem Interface arbeite ich gerne mit Lambda-Funktionen, statt mit den normalen "OnClick" Events
- Weiterhin baue ich mir spezielle "Assign" Funktionen, um auch von unüblichen Datenquellen Zuordnen zu können.
- Wenn Komponenten größere Vorbereitungen und Einstellungen erfordern, lege ich mir gerne "QuickSetup_Yxz" Funktionen an,
die gewisse Standardkonfigurationen abdecken.
- Haben Komponenten kleinere Fehler kann ich diese einfach umschiffen, falls möglich.
- Ein Wechsel von einer Komponente von einem zum anderen Anbieter ist problemlos, wenn ich mein Interface benutze
- Geringere Lernkurve, weil ich mein eigenes Interface möglichst konsistent und "WYSIWYG" halte
Usw.

Die Nachteile, man muss das natürlich erstmal einbauen

Sowas wie DevExpress ist nicht gerade klein.

**Codehunter**

Wenn ich die Wahl hätte, würde ich statt TcxGrid tatsächlich VirtualTreeview mit den Gridextensions nehmen. Kann ich aber leider nicht, das cxGrid ist von der Projektleitung vorgegeben.

Erklären kann ich es nicht, aber irgendwie hab ich den VTV lieben gelernt. Das Ding kann man mit relativ wenig Code praktisch an alles dran flanschen. Als Tree, als Listview und als Grid. Manchmal denkt man gar nicht, dass man einen VTV sieht - z.B. das Datagrid in HeidiSQL.

Beim TcxGrid (oder auch Quantum Grid) scheint es mir genau umgekehrt zu sein. Das Ding ist hochgradig featurisiert, kann unheimlich viel von Haus aus. Weitgehend Klickibunti-Programmierung. Aber kaum will man mal was machen, das eben nicht von Haus aus vorgesehen ist, schon produziert man Unmengen an Code. In meinem Fall läuft das Grid als DBGrid. Dann kommt intern ein anderer Viewer und anderer Controller zum Einsatz, schwupps schon passen die Demos nicht mehr, weil andere Properties. Durch die Trennung in DataController und Viewer sind die Daten in der DB und die angezeigten Daten plötzlich zweierlei und müssen dann in Events wie "OnValidate" wieder zusammengebracht werden. Wenn es dabei Querbezüge zu anderen Zellen im selben Row gibt, braucht man sowas wie TGrid.Cells und genau das gibts nur auf völlig verschlungenen Pfaden. Ich hab mir da jetzt einen Class Helper dazu gebaut. Das muss man sich mal reinziehen: Um an den Value (=Variant) der aktuell fokussierten Zelle zu kommen, braucht es 15 (!!!) Typecasts. Und die muss man sich mühsam per STRG-Klick erstöbern, weil nirgends steht, welche Property vom cxGrid intern auf was gecastet wird. Irgendwie funktionierts, aber handhabbar ist es eigentlich nur über die mitgelieferten Assistenten. Total knülle.

Bzgl. TXmlDocument sehe ich das ähnlich. Das Ding ist ziemlich flexibel. Ich hab auch oft damit zu tun und komme auch damit klar. Was mich daran nervt, ist dass es verschiedene Inkarnationen davon gibt. Einmal die dynamische Version, wo man sich für jeden Knoten ein Objekt "zu Fuß" erstellt. Dann den XML Wizard, der da ein starres Korsett drumrum baut. Das ist initial eine feine Sache, denn man hat in Nullkommanix ein Objekt mit den passenden Properties. Aber will man da später noch was hinzufügen, dann ist es die Hölle. Man schreibt die Interfaces um und die implementierenden Klassen und die ganzen Getter und Setter. Und wehe, das eingelesene XML hat auch nur einen Knoten mehr oder anders groß-/kleingeschrieben: Schon kläfft die Runtime rum von wegen Interface nicht unterstützt usw.

Ich habe mir darum einen Universal-Parser geschrieben, den ich mit XPath anspreche und der die fehlenden Knoten automatisch anlegt. Nicht unbedingt Highend-Performance, aber für kleine Konfigurations-XML völlig ausreichend. Da kommt es historisch gewachsen zu der Situation, dass das selbe XML an verschiedenen Stellen von allen drei Varianten gelesen wird. Dann sieht man die Unterschiede: Dynamisches TXmlDocument 20 Zeilen, vom Wizard importiertes Objekt 10 Zeilen, mein Parser eine Zeile.

**Sinspin**

Zitat von Codehunter:

Nachdem ich die letzten drei Tage viele viele Stunden mit lustigem Property-Suchen verbracht habe, bin ich inzwischen kurz vorm Burnout

...
Heute bin ich wieder genau an dem selben Punkt, nur mit dem TcxGrid von DevExpress.

Ich vote für TcxGrid mit DBBandedTableView .
Für die Tableviews gibt es eine eingebettete Editform die man nur mit einem schrecklichen Designer zusammenklicken kann ohne dass man dabei live Daten sehen könnte.
Die härte ist ein Property (zum an/abschalten des Features

) mit dem man seine gesamte Arbeit einfach in die Tonne k(l)icken kann. Weg, auf nimmerwiedersehen.
TdxNavBar folgt dann mit einigem Abstand. Gehört für mich aber auch zu den Komponenten die sich zwischen genial und unbedienbar bewegen.

Ich kenne den TcxGrid fast solange wie es ihn gibt und verwende ihn wo immer es möglich ist als Lösung der Wahl.

Zitat von Codehunter:

Das muss man sich mal reinziehen: Um an den Value (=Variant) der aktuell fokussierten Zelle zu kommen, braucht es 15 (!!!) Typecasts. Und die muss man sich mühsam per STRG-Klick erstöbern, weil nirgends steht, welche Property vom cxGrid intern auf was gecastet wird. Irgendwie funktionierts, aber handhabbar ist es eigentlich nur über die mitgelieferten Assistenten. Total knülle

Das halte ich für einen "Anfängerfehler". Den Wert der aktuell focusierten Zelle bekommst Du direct einfach so:

markieren

Delphi-Quellcode:

			Column.DataBinding.Field....

// oder :

TableView.Controller.FocusedColumn.DataBinding....

**Codehunter**

Zitat von Sinspin:

Das halte ich für einen "Anfängerfehler".

Das will ich gar nicht ausschließen. Wie hat doch Werner mal so schön gesagt: Ich bin mit der Gesamtsituation unzufrieden

Das cxGrid ist nicht intuitiv bedienbar und die Lernkurve extrem flach. Man kann auf Erfolgen nicht wirklich aufbauen, weil einmal gefundene Wege bei der nächsten Gelegenheit wieder zur Sackgasse werden. Zum Beispiel wenn man einem Column unterschiedliche Properties zuweist. Für alle Unwissenden: TcxGrid hat eine Property namens "Properties" und dieser weist man wiederum eine Properties-Klasse mit Properties zu. Allein schon diese Namenswahl lässt mich schaudern

Und wo ich grad bei Devexpress bin: Das LayoutControl ist auch ziemlich Brainfucking. Es erinnert mich an finstere Zeiten, vor so ca. 30 Jahren, als ich Tabellenlayouts in HTML gebaut habe. Zwar hab ich womöglich dank dieses historischen Wissens inzwischen kapiert wie die Komponente funktioniert und wie man halbwegs brauchbare Layouts damit bauen kann. Aber auch nach mehreren Jahren habe ich noch keinen Weg gefunden, wie man z.B. eins der lustigen Grids mit den vielen mühsam zusammengeklickten Properties von einem LayoutControl zum anderen verpflanzen kann. Oder auch von einem Form zu einem anderen. Die allermeisten VCL-Controls kann man einfach per Clipboard "rüberbeamen". Zickige Exemplare auch schon mal auf dem Zahnfleisch per Texteditor im DFM. Bei TcxIrgendwas und TdxIrgendwas sind beide Wege versperrt. Kopieren geht, aber beim Einfügen fällt alles auseinander wie ein Mikado. Und auf DFM-Ebene sind Devexpress-Komponenten überhaupt nicht ineinander verschachtelt sondern liegen alle flach auf einer Ebene, ohne erkennbare Bezüge zueinander. Deshalb kopiert der IDE-Form-Designer auch nur Fragmente in die Zwischenablage, nie das Gesamtkunstwerk.

**himitsu**

"theoretisch" sind die VCL-Komponenten von DevExpress recht logisch.

Wären da nicht ab und an so inkonsistenzen
innerhalb der selben Komponente, aber auch zu anderen ähnlichen Komponenten.

im DataController die rohen Records und alle Infos dazu
und im Controller alles zum View, also sichtbren Rows/GroupRows.

und teilweise ist es aber auch falschrum oder ganz wo anders

Man darf wirkich alles mehrfach lernen, ist immer verzweifelt am suchen (besser, wenn man die Quelltexte mit gekauft hat) und in der nächsten Version ist es wieder irgendwas kaputt/anders.

Ja, dxGrid+BandedTableView kann schon schlimm sein, aber noch schlimmer ist deren DBTreeView, gefolgt vom PivotGrid, Gantt, cxSheduler und ganz besonders ist das BreadcrumbEdit.

Das LayoutControl hab ich zum Glück nicht selber gemacht ... da hat sich jemand anderes dran verzweifelt versucht.
Das Ding is aber nicht nur im FormDesigner ein Graus, sondern auch der Runtime-Designer für die Kunden ist schon sehr unintuitiv, vorallem wenn man mal versucht einen Splitter zu löschen.

**Sinspin**

LayoutControl, am besten, nicht drüber nachdenken, nicht verwenden und hoffen das keiner danach fragt.
Wir haben mittlerweile so viele Fragen zu allen möglichen Problemen mit Komponenten gestellt und jedesmal die Antwort bekommen das dies oder jenes Problem ein Feature ist und kein Bug... oder das bisher noch keiner eine Änderung brauchte...

Da gibt es von Emba so einen schönen

Blogeintrag mit Emba und DevExpress. Das ließt sich wie, alles ist toll. In real sind die Komponenten Alt und Bocksteif geworden. Was Neues ist auch nicht wirklich hinzugekommen. Für WinForms gibt es eine ganze Menge Komponenten mehr. Andererseits, wenn ich sehe was die letzten Jahre angerichtet wurde... Nichts von dem Zeug ist wirklich flexibel editierbar oder lässt sich ordentlich zur Laufzeit erstellen... will man dann überhaupt noch mehr sowas haben?
Leider ist man ab einem gewissen Punkt in dem Kram gefangen den man sich einst selber aufs Auge gedrückt hat.

**himitsu**

Zitat:

zur Laufzeit erstellen

Ja, da hatte ich damals aufgegeben weiter zu versuchen

Grid+BandedTable zur Laufzeit

Aber das hauseigene DBGrid und DBX von Delphi sind ja noch grauenhafter (von einer Software, die seit "Delphi" sich eigentlich auf Datenbankanwendungsentwicklung verstehen will)