AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Delphi-PRAXiS - Lounge Klatsch und Tratsch Was ist eure "Most brainfucking Delphi component ever?"

Was ist eure "Most brainfucking Delphi component ever?"

Ein Thema von Codehunter · begonnen am 3. Aug 2021 · letzter Beitrag vom 13. Aug 2021
Antwort Antwort
Seite 1 von 3  1 23   
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
2.233 Beiträge
 
Delphi 10.4 Sydney
 
#1

Was ist eure "Most brainfucking Delphi component ever?"

  Alt 3. Aug 2021, 12:06
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
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden
  Mit Zitat antworten Zitat
Benutzerbild von dummzeuch
dummzeuch

Registriert seit: 11. Aug 2012
Ort: Essen
928 Beiträge
 
Delphi 2007 Professional
 
#2

AW: Was ist eure "Most brainfucking Delphi component ever?"

  Alt 3. Aug 2021, 16:26
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.
Thomas Mueller
  Mit Zitat antworten Zitat
freejay

Registriert seit: 26. Mai 2004
Ort: Nürnberg
236 Beiträge
 
Delphi 10.4 Sydney
 
#3

AW: Was ist eure "Most brainfucking Delphi component ever?"

  Alt 3. Aug 2021, 17:01
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
[Delphi 10.4.1 Sydney Enterprise; Win10; MySQL; VCL]
  Mit Zitat antworten Zitat
Rollo62
Online

Registriert seit: 15. Mär 2007
3.212 Beiträge
 
Delphi 10.4 Sydney
 
#4

AW: Was ist eure "Most brainfucking Delphi component ever?"

  Alt 3. Aug 2021, 17:52
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.
  Mit Zitat antworten Zitat
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
2.233 Beiträge
 
Delphi 10.4 Sydney
 
#5

AW: Was ist eure "Most brainfucking Delphi component ever?"

  Alt 3. Aug 2021, 18:34
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.
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden

Geändert von Codehunter ( 3. Aug 2021 um 18:40 Uhr)
  Mit Zitat antworten Zitat
Sinspin

Registriert seit: 15. Sep 2008
Ort: Dubai
202 Beiträge
 
Delphi 10.3 Rio
 
#6

AW: Was ist eure "Most brainfucking Delphi component ever?"

  Alt 3. Aug 2021, 19:40
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.

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....
Stefan
Wir zerstören die Natur und Wälder der Erde. Wir töten wilde Tiere für Trophäen. Wir produzieren Lebewesen als Massenware um sie nach wenigen Monaten zu töten. Jetzt rächt sich die Natur und tötet uns.
  Mit Zitat antworten Zitat
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
2.233 Beiträge
 
Delphi 10.4 Sydney
 
#7

AW: Was ist eure "Most brainfucking Delphi component ever?"

  Alt 3. Aug 2021, 20:53
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.
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
38.575 Beiträge
 
Delphi 10.4 Sydney
 
#8

AW: Was ist eure "Most brainfucking Delphi component ever?"

  Alt 3. Aug 2021, 22:43
"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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014

Geändert von himitsu ( 3. Aug 2021 um 23:06 Uhr)
  Mit Zitat antworten Zitat
Sinspin

Registriert seit: 15. Sep 2008
Ort: Dubai
202 Beiträge
 
Delphi 10.3 Rio
 
#9

AW: Was ist eure "Most brainfucking Delphi component ever?"

  Alt 3. Aug 2021, 23:01
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.
Stefan
Wir zerstören die Natur und Wälder der Erde. Wir töten wilde Tiere für Trophäen. Wir produzieren Lebewesen als Massenware um sie nach wenigen Monaten zu töten. Jetzt rächt sich die Natur und tötet uns.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
38.575 Beiträge
 
Delphi 10.4 Sydney
 
#10

AW: Was ist eure "Most brainfucking Delphi component ever?"

  Alt 3. Aug 2021, 23:11
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)
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014

Geändert von himitsu ( 3. Aug 2021 um 23:13 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 3  1 23   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +2. Es ist jetzt 21:49 Uhr.
Powered by vBulletin® Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf