Was ist eure "Most brainfucking Delphi component ever?"

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

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)

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