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.