Ich nutze zwar weder "TcxVirtualTreeList" noch "TcxTreeListCustomDataSource", habe dieses Grundsatzproblem aber selbst logisch wie folgt gelöst:
Mein "linearisierter Baum" arbeitet im
GUI und bei der Nutzung stets voll virtuell, es gibt im Speicher eines Nodes nur temporär ChildNodes welche gerade angefragt werden
Es bei mir haben Nodes folgende Minimale Grundstruktur
//stored => so einfach "linear" in der
DB-Table
- NodeID: eineindeutige UID, z.B.
DB-AutoIncrement
- ParentID: NodeID des ParentNodes oder wenn ein "Root" gleich der eigenen NodeID
- Data1: beliebige Daten
- Data2: beliebige Daten
- Data3: beliebige Daten
//private => nur Temporär im Speicher
- RootPtr als schneller "BackLink"
- ChildIDs als NULL oder TList<NodeID>
- TimeStamp als 0 oder letztes Sync, einfach als "PrimitivCache".. wird mit immer mit dem "globalen" TimeStamp des Root verglichen, TimeStamp des Roots aktualisiert sich bei allen Move,Insert,Delete Operationen(aber nicht bei "DataChange" weil DataValues nie im Cache) wenn sich nicht der ChildSelbst um die Benachrichtigung(zur Aktualisierung) seines Parents kümmert, sodass das globale ungültig machen aller Caches so umgangen werden kann
Das Konzept stammt noch aus Zeiten von Delphi2007 32Bit, da war mir das mit 32Bytes per Node eine Löung um auch Millionen von Nodes als Records in einer simplen
DB Struktur zu halten und effektiv per einfachstem
SQL anzufordern oder gefiltert abzufragen
Code:
Abfrage aller RootNodes
select * from NodeTable where NodeID = ParentID
Abfrage aller RootNodes mit z.B. Filtervergelichswert :Data1
select * from NodeTable where NodeID = ParentID and Data1 = :Data1
Abfrage aller ChildNodes zu einer NodeID
select * from NodeTable where ParentID = :NodeID
Abfrage aller ChildNodes zu einer :NodeID mit z.B. Filtervergelichswert :Data1
select * from NodeTable where ParentID = :NodeID and Data1 = :Data1
Ich habe mir den
SQL Kram je nach NodeDataTyp jeweils direkt in Getter&Setter und Setter der NodePropertys gebracht.. ein universelles ORM oder eine ganz sauberer eigener
DB-VirtualTreeView/Node war nie mein Ziel, ich verwende dies auch heute oft noch als CodeTemplate per Copy&Paste und passe fix den Namen der Nodeklasse an und benenne sowie typisiere Data1.., dann nur noch passend auch das
SQL dazu und gut is.
Zumindest wäre dein Ziel ein trotz Rekursivität möglichst effektives ZeitVerhalten auch bei Datenfiltern zu behalten aus meiner Erfahrung so durchaus gegeben, der Trick ist hier ja einfach die lineare Indexbasierte Suche und Datenhaltung hinter/neben dem TreeView
Ich denke, diese Grundlogik könnest du übernehmen und wirst die passenden Events oder Gett&Setter auch in "TcxVirtualTreeList..." finden.
Ersetze in deinen Gedanken einfach dein Child[Index] gegen ein Child[NodeID] was du bei passender
DB-Struktur wie und wo auch immer stets einigermaßen deterministisch auswählen und nutzen kannst.
Sollte ich deine Fragestellung nach Suche und Select mit Filtermöglichkeit doch nicht richtig und für dich passend getroffen haben, dann liegt es eventuell daran, dass ich mich explizit nicht um die Frage Stellung "GetChildCount" & "GetChildRecordHandle" mit einem echt BaumBasierten Filter&Such Algo gekümmert habe, mich also die Baumtiefe bis zu den Blättern bei dieser Zugriffs&Filterlösung garnicht interessiert.