TreeView mit 200.000 Einträge und nachladen

[jaikai]

Hi Leute,

ich habe eine TreeView, die später 200.000 Einträge hat. Alles auf einmal zu laden wäre Wahnsinn.

Aber - es gibt das (Explorerartige) Verfahren des nachladens und entladen der Knoten.

Kann mir mal bitte jemand im Schnelldurchlauf schreiben, wie dies funktioniert?

Danke

[xaromz]

Hallo,

dazu geht man folgendermaßen vor: Die Knoten der aktuellen Ebene erstellen. Nachschauen, welche Knoten Unterknoten besitzen. Dort jeweils einen Dummyknoten einfügen, damit ein Pluszeichen erscheint. Im OnChange-Ereignis prüfen, ob ein Dummyknoten existiert, dann diesen löschen und stattdessen die Ebene einlesen.

Gruß
xaromz

[jaikai]

Die NAchtarbeiter sind ja mal wieder Fix - Danke!

[sh17]

Zitat:

Zitat von xaromz

Die Knoten der aktuellen Ebene erstellen. Nachschauen, welche Knoten Unterknoten besitzen. Dort jeweils einen Dummyknoten einfügen, damit ein Pluszeichen erscheint. Im OnChange-Ereignis prüfen, ob ein Dummyknoten existiert, dann diesen löschen und stattdessen die Ebene einlesen.

Nicht unbedingt optimal.

Besser eine virtuelle Variante einer TreeView verwenden, die läd die Daten erst, wenn Sie in den Sichtbereich rücken. Sehr scnell.

kostenlose Variante unter

http://www.soft-gems.net/VirtualTreeview/

[Lannes]

Hallo,

einen Dummyknoten einfügen ist nicht erforderlich, es reicht folgendes:

Delphi-Quellcode:

TreeView1.Selected.HasChildren := True;
//...
if TreeView1.Selected.HasChildren then
  //Knoten laden

[xaromz]

Hallo,

Zitat:

Zitat von Lannes

Hallo,

einen Dummyknoten einfügen ist nicht erforderlich, es reicht folgendes:

Delphi-Quellcode:

TreeView1.Selected.HasChildren := True;
//...
if TreeView1.Selected.HasChildren then
  //Knoten laden

ist zwar richtig, aber dann kann man nicht feststellen, ob man hier noch was reinladen muss oder das schon gemacht hat.

Gruß
xaromz

[dfried]

Zitat:

Zitat von xaromz

ist zwar richtig, aber dann kann man nicht feststellen, ob man hier noch was reinladen muss oder das schon gemacht hat.

Wenn "Count" 0 ist, dann muss noch geladen werden.

[Lannes]

Hallo,

feststellen ob noch geladen werden muss:

Delphi-Quellcode:

if (TreeView1.Selected.HasChildren) and
   (TreeView1.Selected.Count = 0) then
  showmessage('Noch Laden');

[jaikai]

Weiterführende Fragen zum Thema - weil ich total verwirrt und irgendwie orientierungslos geworden bin. In den Foren gibsts nur ansatzweise Abhilfe meines Problems.

Zitat:

xaromz --> dazu geht man folgendermaßen vor: Die Knoten der aktuellen Ebene erstellen. Nachschauen, welche Knoten Unterknoten besitzen. Dort jeweils einen Dummyknoten einfügen, damit ein Pluszeichen erscheint. Im OnChange-Ereignis prüfen, ob ein Dummyknoten existiert, dann diesen löschen und stattdessen die Ebene einlesen.

Ohne Betriebsgeheimnisse stehlen zu wollen:
Irgendwie ist mir nicht klar, wie ich die notwendige Datenstruktur hierzu erstellen muß. Ich habe 200.000 Einträge, die ich beliebig zusammenstellen kann. Als #09-Einrückern formatiert und load - benötigt der komplette Baum ca 20-30 sec. Einzelne Root-Zweige bis zu 8 sec. Das ist mir zu lang.

Oder aber wie diess (so wie ichs gern verwenden würde, weil ich hier das Icon, die passende Verlinkung und mehr bereits integrieren kann):

Delphi-Quellcode:

Datei    Knoten
|        |  NodeText
|        |  |
00097498:00:Root-Knoten ganz unten (00) -> davon gibts 50 Stück
00097499:01:Unterknoten 0-1
00097500:02:Unterknoten 0-2
00097501:01:Unterknoten 0-3
00097502:02:Unterknoten 0-3-1
00097503:02:Unterknoten 0-3-2
00097504:03:Unterknoten 0-3-2-1
etc

Fragen:

--> Die Knoten der aktuellen Ebene erstellen...
Benötigt eine Datei mit diesem Index oder aber Handarbeit. Benötigen die SubEinträge denn ebenfalls jeweils Dateien, die geladen und eingefügt werden? Oder kann ich nicht dem Knoten so etwas wie einen neuen absoluten Index verpassen, der meinem zweiten Modell entspricht? Ich hab gelesen, ein Objekt zuordnen würde gehen, finde aber keine Hinweise, wie das geht.

--> Im OnChange-Ereignis prüfen, ob ein Dummyknoten(HasChildren)existiert
Nachfrage dessen ist mir klar - aber das ganze müßte dann wieder gestoppt werden. Also eine Begrenzung des füllens. Ebene einlesen - sieht wieder nach indizierten Dateien aus, oder Abfragen, ob der Sub-Eintrag noch Childs enthält, dann break. Ich will die Erzeugung von möglichen 200.000 Dateien vermeiden. Wie geht das?

Wenn ich keine Urheberrechte verletze, hat jemand ein paar Source-Beispiel für mich? Ich blick da nicht wirklich durch.

Danke

:?

[sh17]

Zitat:

Ich habe 200.000 Einträge, die ich beliebig zusammenstellen kann. Als #09-Einrückern formatiert und load - benötigt der komplette Baum ca 20-30 sec. Einzelne Root-Zweige bis zu 8 sec. Das ist mir zu lang.

Ich kann nur nochmal auf die virtuelle Variante in meinem vorherigen Posting verweisen. Die wird auch einige Deiner anderen Probleme lösen.

[Kroko1999]

Moment mal bitte, ich würde doch erst einmal darüber nachdenken, wer 200.000 (in Worten: zweihundertausend) Einträge mehr oder weniger lesen möchte -> ich nicht! Also ist es wahrschenlich besser, sich Gedanken über die Einteilung der Einträge in bestimmte Kategorien zu machen und das ganze Problem so lange zu unterteilen, bis eine lesbare Verteilung entsteht, oder :gruebel: !

[sh17]

Deswegen wird es mit dem Nachladen von Zweigen nicht schneller, auch wenn Sie nur noch 5000 Einträge haben. Und 5000 Einträge sind nicht unrealistisch.

Mit der TreeView-Variante werden alle 5000 Einträge geladen. Mit der virtuellen Variante nur die sichtbaren 50. (Je nachdem, wir groß das Control ist).

[Kroko1999]

Ich möchte auch keine 5000 Einträge lesen (maximal 50)!

[sh17]

Praktisches Beispiel:

Leistungsverzeichnis mit mehreren Titeln (Knoten). Die untersten Titelebenen enthalten jeweils rund 2000 Positionen.

Die wird man sicher durchlesen und mit Preisen verpassen müssen, auch wenn man nicht will.

[Kroko1999]

Zitat:

Zitat von sh17

Praktisches Beispiel:

Leistungsverzeichnis mit mehreren Titeln (Knoten). Die untersten Titelebenen enthalten jeweils rund 2000 Positionen.

Die wird man sicher durchlesen und mit Preisen verpassen müssen, auch wenn man nicht will.

NEIN, dann möchte ich das Ganze nach Anfangsbuchstaben etc. selektieren können, niemand liest mehr als 50 Einträge konzentriert durch!

[alzaimar]

Die schnellste Möglichkeit, den Baum dynamisch nachzuladen ist die, die Datei korrekt zu sortieren, sodaß Du relativ fix die nachzuladenden Knoten ermitteln kannst. Du kannst versuchen, die Bauminformation in einer einfach TStringlist zu laden. Das ist relativ fix.

Wenn Du nun einen Knoten expandieren willst, dann suchst Du das erste 'Kind' der neuen Unterebene. Ab da liest Du aus der Stringliste einfach alle Elemente dieser Ebene ein. Eine Stringliste mit 200.000 Elementen durchzulaufen geht innerhalb von ein paar ms, also kein Problem. Wichtig ist, das Du anhand eines Schlüssel erkennst, welche Knoten zusammengehören, und das sehe ich bei deinem Verfahren nicht. Für die Root-Ebene ist das einfach '00', aber für die Kinder des 3.Rootknotens ist das nicht gegeben. Deshalb wäre es ratsam, Jedem Knoten eine ID zu geben, und zwar so (rekursiv definiert):

Delphi-Quellcode:

Function ID (Knoten)
  If Knoten = Nil Then 
    Result  := ''
  Else
    Result := ID (Knoten.Parent)+'/'+Knoten.Index

Nach dieser ID sortierst Du die Stringliste.

Um nun alle Kinder eines Knotens mit einer bestimmten ID 1/2/3 zu laden, suchst Du einfach den Eintrag 1/2/3/0. Das ist das erste Kind. Ab da gehst Du sequentiell in der Stringliste weiter (die ist ja nach der ID sortiert), bis die einzulesende ID nicht mehr dem Muster 1/2/3/* entspricht.

Das sollte ohne Verzögerungen gehen. Ich teste das gleich mal und poste dann hier (wenn ich mich nicht zum Horst mache), eine Demo.

[generic]

ich glaube nicht das das windows control treeview soviele einträge verkraftet oder performat darstellen kann.

ich empfehle dir auf dem virtualstringtree umzusteigen.
diesen gibt es hier: http://www.lischke-online.de/

[jaikai]

--> ich glaube nicht das das windows control treeview soviele einträge verkraftet oder performat darstellen kann.

Aber klar doch verkraftet die TV soviele Einträge! Ich habs doch schon durchprobiert. Nur die Ladezeiten stören mic wirklich.

--> Kroko...

Liest Du dir ein ganzes Lexikon durch um den Begriff "Dumm" zu finden oder schaust du unter "D" nach? Und wenn Du noch wissen willst, woher das Wort kommt, so - stöbern und begreifen - lieste Dir dann noch was ethnomythologisches durch? Bischen dümmlich, Deine Maxime...

---> generic
Ich hab nur ne offizielle D5, und keine alte VirtuTV Version. Theme wird nicht unterstützt und ich kaufe mir für 200.000 Eiträge nicht ne neue Version. Die alte ist mühsamer, aber für das was ich will, reicht sie in allen Bereichen. Ist nur Bei - nicht Hauptwerk.

---> alzaimar

Erstma Danke, und ich hoffe, Horst hat Ruhe.
Das Indizieren der Zugehörigkeit ist nicht so wild, das ist bloß Schreibarbeit. Die Daten liegen vor und ich kann sie verbiegen, wie ich will.

Danke

[alzaimar]

Zitat:

Zitat von generic

ich glaube nicht das das windows control treeview

Doch doch, das klappt. Das "Problem" ist die Datenstruktur, damit man schnell alle Kind-Einträge eines Unterknotens findet. Das gleiche Problem tritt bei der VST von Lischke auf.

Derzeit habe ich eine Verzögerung von 200-300ms (PM 1.5Ghz) bei jedem Klick, wenn der Knoten noch nicht befüllt wurde), bei 200.000 Einträgen. Das ist schon ganz ordendlich. Man kann es auf fast 0ms Verzögerung reduzieren, wenn man die Baum-Information geeignet ablegt. Dann geht das Suchen sehr schnell.

Die Bottlenecks lassen sich auf zwei Routinen reduzieren:
1. Ist ein Texteintrag ein Kindknoten eines vorgegeben Knotens?
2. Existieren für einen Knoten überhaupt Kinder?

Wenn die Bauminformation so gespeichert wird, das der Index des Vaters für jeden Knoten mit abgespeichert wird, dann kann man (1) vernachlässigen.
Wenn die Anzahl der Kinder auch gespeichert wird, dann wird auch (2) vernachlässigbar.

Beide Optimierungsmöglichkeiten sind in dieser Demo nicht berücksichtigt. Man könnte es aber ohne Weiteres einbauen. Ich würde die Baumdaten auch nicht als Text, sondern als geeignete Struktur ablegen (in einem Stream, z.B.) dann geht das Laden und Suchen sehr schnell, eigentlich ohne Verzögerung.

[Kroko1999]

Zitat:

Zitat von jaikai

...
--> Kroko...

Liest Du dir ein ganzes Lexikon durch um den Begriff "Dumm" zu finden oder schaust du unter "D" nach? Und wenn Du noch wissen willst, woher das Wort kommt, so - stöbern und begreifen - lieste Dir dann noch was ethnomythologisches durch? Bischen dümmlich, Deine Maxime...
...

nein, eben nicht, deswegen stand dort etc., aber ich suche nicht D und gehe alle Worte bis DUMM durch, sondern
D ->
DU ->
DUM ->
DUMM gefunden.

Meine Maxime mag eigen sein, bestimmt nicht dümmlich (PS: Toller Tonfall über andere Meinungen), aber glaubst Du wirklich jemand liest sich bei voller Konzentration 2000 Einträge durch? NIE MALS, überprüfe Dich doch mal selbst! Die Strategie "TEILE und HERRSCHE" entstand nicht einfach so, sondern .. naja.
@jaikai
Trotzdem finde ich Deinen Tonfall nicht gut, aber wenn Du es so haben möchtest, erstelle Dein Programm mit soviel Einträgen, wie Du willst, auf meine Hilfe zähle nicht mehr!

[jaikai]

Genau das issses! :)))

Klasse!
Hübsch schnell
Den Rest werd ich mir zurechtfummeln!

Vielen Dank!

[alzaimar]

Halt! Stop! Wat'n hier los? :gruebel:

Kommt mal alle runter, der Tonfall wurde wirklich überflüssigerweise ausfallend! Was soll das?

Es ist nicht dümmlich, beim Programmieren von extremen Voraussetzungen auszugehen, im Gegenteil: Es ist die einzig sinnvolle Vorgehensweise. Natürlich muss man keine Vorkehrungen treffen, das eine Anwendung auch bei 100.000.000 Items performant reagiert, wenn der reale Extremfall bei z.B. 1000 liegt, aber es sollte schon so sein, das man die Anwendung dezent überdimensioniert, insofern ist die Zahl '5000' eigentlich noch pessimistisch.

Also: Alle wieder :kiss: und später :cheers: , sonst :warn:

[jaikai]

Oh Kroko -
ich will dich nicht beleidigen, zumindest nicht wirklich.

Aber der Sinn eines Registers liegt nuneinmal in der Aufsplittung. Damit man sich eben nicht alles durchlesen muß! Aber zum zwecke einer Rückverfolgung oder einer verpasten Abzweige muß der ganze andere Kram eben auch noch mit rein. So wie ein Streckenplan der Bahn. Da kannste keine Bahnhöfe auslassen, bloß weil einer nicht alle kennen will.

Es ist ignorant, eine Meinung wie "Ich les das nicht" allgemein breitzutreten. Aber ich würde auch keine 200000 Einträge lesen. Aber mein Kunde will es vermutlich! :)

okay?

[Sharky]

Zitat:

Zitat von jaikai

... Liest Du dir ein ganzes Lexikon durch um den Begriff ...

Und STOP :warn:

Lieber jaikai,

weder wir im Team noch andere User der DP möchten noch einmal lesen das ein andere User als "dumm" bezeichnet oder es auch nur angedeutet wird :!:

Bitte überdenke deine Postings bevor Du hier noch solche Sachen schreibst. Wir haben in der Delphi-PRAXiS einen freundlichen und höflichen Umgang miteinander und möchten auch das dies so bleibt.

Danke.

[Kroko1999]

Zitat:

Zitat von jaikai

...
So wie ein Streckenplan der Bahn. Da kannste keine Bahnhöfe auslassen, bloß weil einer nicht alle kennen will.
...

Mir reichen aber alle Bahnhöfe von A nach B, ich muss nicht alle anderen kennen! Das heißt jedoch auch wieder, es muss eine Vorauswahl getroffen werden, egal nach welchen Gesichtspunkten!

[jaikai]

Aber in jeder U-Bahn hängt der komplette Streckenplan, weil man eben nicht weiß, was der U-bahn-U-ser sich ansehen will. Und so ist da auch bei mir.

[alzaimar]

Zitat:

Zitat von Kroko1999

Mir reichen aber alle Bahnhöfe von A nach B, ich muss nicht alle anderen kennen! Das heißt jedoch auch wieder, es muss eine Vorauswahl getroffen werden, egal nach welchen Gesichtspunkten!

Code:

SET EINMISCHMODE ON

Genau das macht jaikai doch, er zeigt in einer Ebene 'Bahnhöfe','Museen','Dönerbuden'. Wenn man auf 'Bahnhöfe' klickt, erscheinen 'S-Bahnhöfe','U-Bahnhöfe' und 'DB-Bahnhöfe', usw... Also?

Code:

SET EINMISCHMODE OFF

[marabu]

Darf ich auch?

Es ist im Verlauf der Diskussion der nachvollziehbare Eindruck entstanden, 200.000 Einträge würden auf 50 top level nodes verteilt - und zwar ohne weitere Untergliederung. Der Beitrag #9 des OP gibt zwar einen versteckten Hinweis auf eine weitere Untergliederung, aber ich will es Kroko nicht verdenken, dass er das überlesen hat. Die Darstellung ist wirklich suboptimal.

Hätte JK seinen Tree mit order und height beschrieben, dann hätte auch ich schneller Bescheid gewusst. Bin anfangs auch davon ausgegangen, dass es sich um einen total entarteten Baum handelt und, nachdem die richtigen Hinweise kamen und nicht so richtig fruchteten, dachte ich hier ist Rat und Hilfe fehl am Platz. Wieder ein Lehrstück für meine Sammlung von problem statements.

Es findet sich in der DP immer jemand der trotzdem versteht (hallo alzaimar) - ist das nicht toll?

Freundliche Grüße vom marabu