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 :evil:

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? :lol:

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

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 :wink:

[Rollo62]

Zitat:

Zitat von Codehunter (Beitrag 1493165)

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 :stupid:
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:

Zitat von Codehunter (Beitrag 1493165)

Nachdem ich die letzten drei Tage viele viele Stunden mit lustigem Property-Suchen verbracht habe, bin ich inzwischen kurz vorm Burnout :evil:
...
Heute bin ich wieder genau an dem selben Punkt, nur mit dem TcxGrid von DevExpress.

Ich vote für

Delphi-Quellcode:

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.

Delphi-Quellcode:

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:

Zitat von Codehunter (Beitrag 1493184)

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:

Delphi-Quellcode:

Column.DataBinding.Field....
// oder :
TableView.Controller.FocusedColumn.DataBinding....

[Codehunter]

Zitat:

Zitat von Sinspin (Beitrag 1493188)

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 :-D 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 :twisted:

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)

[Codehunter]

Zitat:

Zitat von Sinspin (Beitrag 1493201)

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

[Rollo62]

Zitat:

Zitat von Sinspin (Beitrag 1493201)

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:

Zitat von dummzeuch (Beitrag 1493174)

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:

Zitat von dummzeuch (Beitrag 1493220)

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 :wall:
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 :o

[Jumpy]

Zitat:

Zitat von ULIK (Beitrag 1493434)

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:

Zitat von Codehunter (Beitrag 1493435)

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

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.

[uligerhardt]

Zitat:

Zitat von Codehunter (Beitrag 1493525)

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.

Ich dachte da eher an Sachen wie eingebaute Sortierung, Filterung und Gruppierung in Gridspalten. Ob man Skinning haben muss, kann man sich streiten. 8-)

[Codehunter]

Zitat:

Zitat von uligerhardt (Beitrag 1493527)

Ich dachte da eher an Sachen wie eingebaute Sortierung, Filterung und Gruppierung in Gridspalten. Ob man Skinning haben muss, kann man sich streiten. 8-)

Mir wäre nie in den Sinn gekommen, die Sortierung als Pro-Feature zu sehen. Bei einem DB-Aware-cxGrid könnte ich dem noch zustimmen. Zeigt das Grid hingegen In-Memory-Daten oder Objektproperties, dann ist die frei implementierbare Sortierung beim VST Gold wert. Zumal die ziemlich einfach zu implementieren ist - wenn man wie gesagt das Funktionsprinzip vom VST erst einmal begriffen hat.

Vielleicht mag ich es auch einfach nur nicht, bevormundet zu werden und nur mit vordefinierten Funktionen arbeiten zu müssen.