Was ist eure "Most brainfucking Delphi component ever?"

[Codehunter]

Zitat von Sinspin:

Leider ist man ab einem gewissen Punkt in dem Kram gefangen den man sich einst selber aufs Auge gedrückt hat.

Bingo! Vendor-Lock-In. Wenn man eine große Anwendung hat, mit ein paar Mio. Zeilen Code, dann wirft man nicht mal eben im Handstreich sämtliche UI-Komponenten über den Haufen.

Nur welche dann? Etwas funktional gleichwertiges ist kaum zu finden. Folglich müsste man neben dem UI wohl auch das Bedienkonzept über den Haufen werfen.

Vielleicht erlebe ich es ja noch, dass unsere Firma noch einmal ein Major-Release angeht. Dann wirds sicher nicht wieder Devexpress werden. Aber das kann noch 20 Jahre dauern...

[Rollo62]

Zitat von Sinspin:

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

Genau deshalb habe ich schon vor Jahren die GROSSEN Libraries rigoros rausgeworfen, und seitdem kleine, aber selbst gemanagte Komponenten gesetzt.

Man kann mit DevExpress/TMS/etc. schnell einen beeindruckenden Prototypen hinzaubern,
aber wenn es dann ins Detail geht poppen die Probleme hoch, und ich hatte da zumindest damals von TMS keinen echten Support bekommen.

Ich nutze nun nur noch externe Komponenten die ich wirklich brauche, und nicht selber machen möchte, Grids gehören nicht dazu.
Zum Beispiel DiagramEditor, Scripter, etc., das macht für mich Sinn, aber "Standardkomponenten" mache ich lieber selbst.

Als Ersatz für große Libraries funktionieren bei mir die TFrames super, da baue ich mir einen View so zusammen wie ich es brauche,
z.B. Grid mit allen Bedienelemente, und füge es dann als ganzes in ein Projekt per Runtime ein.
So bekomme ich nach und nach immer mehr zuverlässige, wiederverwendbare Frame-"Komponenten", die ich über Interfaces benutzen und Testen kann.
Brauche ich Abweichungen davon, starte ich mit dem nahestehenden Basis-Frame Interface, und mache mir einfach schnell eine Variante.

[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

[Stevie]

LiveBindings...

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