Was ist eure "Most brainfucking Delphi component ever?"

[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

[uligerhardt]

Zitat von Codehunter:

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

Also, ich mag meine DevEx-Komponenten. Ja, sie sind etwas over-engineered und manchmal sucht man lange nach einer "einfachen" Einstellung. Und manches lässt sich nur mit Aufwand anpassen. Aber sie funktionieren, haben viele nette Features und der Support ist gut. Ich finde, man kann damit klarkommen, und Alternativen gibt's auch nicht wie Sand am Meer (wobei ich mich mit TMS nicht groß auseinandergesetzt habe).

[Codehunter]

Also dieser Thread ist ja inspiriert vom TcxGrid und da nehm ich doch 1000x lieber den VirtualTree. Auch wenn dem so mehr oder weniger relevante Features wie Skinning und Schriftskalierung fehlen. Erstens um Größenordnungen weniger Code im Projekt und zweitens längst nicht so träge.

[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

[Stevie]

LiveBindings...