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

[dummzeuch]

Zitat von dummzeuch:

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.

Nachtrag: Am Montag hatten wir wieder Spaß damit: Anscheinend ändert der MSXML-Parser manchmal auch das FPUControlWord, und zwar von einer Genauigkeit von 64 Bit auf 56 Bit. Und plötzlich rechnete unser Programm beim zweiten Durchlauf (ohne dass es beendet wurde) mit denselben Daten andere Ergebnisse aus. Mein Kollege ist fast verzeifelt, weil er sich das nicht erklären konnte. (Und dann kam der Guru ... )

Das kann einem natürlich auch mit anderen DLLs passieren, insbesondere beim erstmaligen Laden (vgl. auch SysUtils.SafeLoadLibrary), aber es ist der neueste Brainf*ck mit dieser Komponente.

[Codehunter]

Zitat von dummzeuch:

Anscheinend ändert der MSXML-Parser manchmal auch das FPUControlWord

Schon mal mit einem anderen Backend (z.B. OmniXML) probiert? Das ist eigentlich auch so ein Punkt der für TXmlDocument als "MbfDCe" spricht: Man kann den Parser allein dadurch austauschen, dass man die entsprechende Unit ins Uses aufnimmt. Aber wehe dem, der da versehentlich zwei Parser-Units drin stehen hat (womöglich weil die Uses-Klausel schon sehr lang ist). Dann wird nicht etwa der letzte Eintrag im Uses der bestimmende, wie es bei Delphi üblich ist, sondern es bleibt der erste maßgebend. Da kann man sich dann schon mal eine Weile damit beschäftigen, warum sich der neue Parser auch nicht anders/besser als der alte verhält ^^ (Ist aber auch schon eine Weile her dass ich mich mit alternativen XML-Backends befasst habe, glaube bei XE2, also falls sich daran inzwischen was geändert hat, bitte korrigieren!)

[ULIK]

Mein aktueller Favorit ist gerade die Skin-Komponente vom DevExpress
Das Ding ist mächtig ohne Ende, nur einen neuen Skin damit zu erstellen ist grad mein persönliche Horror.

Eigentlich war die Aufgabe, den bestehenden Skin herzunehmen und die Farben (und NUR die Farben) zu ändern um einen dunklen Skin zu bekommen.
Erster Versuch: Abändern eines bestehenden dunklen Skins: gescheitert, da sich dabei auch die Formen, das Aussehen von Elementen sowie Abstände geändert haben.
Zweiter Versuch: bestehenden Skin hernehmen und Farbe abändern. Jetzt müßte man halt wissen, was per Farbe gesteuert wird und was per Bild. Ich acker grad jedes der Elemente durch und vergleich die Mausklick für Mausklick im Skineditor. Herzlichen Dank!
dritter Versuch: naive Idee: die XML-Datei der Skins vergleichen. Gut gemeint, nur stehen dort nur die Änderungen zum ParentSkin drinnen, sprich ich keine Ahnung was der ParentSkin wo definiert.

Wenn also irgendjemand eine Idee, hat, wie man ohne tagelanges Geklicke etc. die Farbe eines Skins anpassen kann, so daß sich NUR diese ändert, nur her damit.

[Codehunter]

Wow, DevExpress schon 3x für die goldene Himbeere nominiert

[Jumpy]

Zitat von ULIK:

Das Ding ist mächtig ohne Ende

Da zeigt sich wieder das zu selten beachtete Sprichwort:

Aus großer Macht folgt große Verantwortung, bzw. angepasst:
Aus großer Mächtigkeit folgt großer Dokumentationsbedarf

[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.