TreeNode zu String suchen

Hallo zusammen

Ich habe einen Treeview der, je nach dem auf welcher Ebene man sich befindet, ein neues Usercontrol anzeigt.
In diesem Usercontrol befindet sich eine Tabelle mit den Details zu den ChildNodes des angewählten Node.
Nun möchte ich dem User die Möglichkeit bieten, mittels Doppelklick in der Tabelle ein bestimmtes Childnode anzuwählen.
Dies funktioniert eigentlich gut, jedoch wird der Treeview nicht aktualisiert.

Ich möchte dies mit dem Befehl treeview.SelectedNode machen, jedoch kann ich den Namen des ChildNode nur als String auslesen, da er aus der Tabelle stammt.

Kann mir jemand einen Tipp geben, wie ich trozdem das bestimmte Node auswählen kann?

Hallo chanderegg,

TreeView.Nodes.Find

herbivore

Diesen Weg habe ich auch schon ausprobiert. Das Problem dort war, dass es ein Array erstellt und wenn ich dann treeview.SelectedNode = a[0] eingebe, wird eine Index out of Range Exception geworfen.

Ich habe überprüft, ob der Name nach dem ich suche auch wirklich der Richtige ist und es hat gestummen. Also müsste es zumindest einen Node finden.

Hallo chanderegg,

bei Find wird nach der Name-, nicht nach der Text-Eigenschaft gesucht. Die müsstest du für alle Knoten auf den gleichen Wert wie die Text-Eigenschaft setzen.

Oder du machst dir gleich ein eigenes Dictionary<string,TreeNode>, in das du jeden Knoten unter seinem Text einträgst.

herbivore

bei Find wird nach der Name-, nicht nach der Text-Eigenschaft gesucht. Die müsstest du für alle Knoten auf den gleichen Wert wie die Text-Eigenschaft setzen.

Also diese Überladung von TreenodeCollection.Add() verwenden:

Public Overridable Function Add(ByVal key As String, ByVal text As String) As System.Windows.Forms.TreeNode
    Member von System.Windows.Forms.TreeNodeCollection

Zusammenfassung:
Creates a new tree node with the specified key and text, and adds it to the collection.

und für key und text denselben String angeben.
Nur dann findet TreenodeCollection.Find(key) einen Treenode (oder gibt null zurück).

Das mittm Dictionary ist doch schlechtes Design, das muß ja nachgepflegt werden, wenn etwa Nodes entfernt/hinzugefügt werden. Und nur den Text kannste auch nicht nehmen, es können ja auf verschiedenen Ebenen derselbe Text vorkommen, also müssteste den Fullpath nehmen.

Hallo ErfinderDesRades,

Das mittm Dictionary ist doch schlechtes Design

nö. Ich hab es so verstanden, dass das TreeView statisch und der Text eindeutig ist.

Davon abgesehen könnte man überlegen, das Dictionary so zu kapseln, dass es automatisch in sync bliebt.

Nur am Rande: Bei sehr großen TreeViews würde man bei Find im Gegensatz zu einem Dictionary lange Laufzeiten bekommen.

herbivore

mag sein, dass der Treeview statisch ist, in diesem Fall.

Aber die Eindeutigkeit der Texte? - je größer der TV, desto unsicherer.

Root - Addressen - Strasse - "Auf der Mauer"
     \
       Addressen - Name - "Auf der Mauer"

Ein nur mit "Auf der Mauer" gefüttertes Dictionary wird streiken.

Bei sehr großen TreeViews würde man bei Find im Gegensatz zu einem Dictionary lange Laufzeiten bekommen.

find sucht ja nur in einem TreeNode.
Also normalerweise, riesige Treeviews sind ja verästelt, grad um große Datenmengen zu strukturieren.
Also ein Treenode mit 100 direkten ChildNodes wäre in meinen Augen schon entartet, z.B. beim durchscrollen würde man leicht die Orientierung verlieren.

Hallo ErfinderDesRades,

Aber die Eindeutigkeit der Texte?

Wenn die Texte nicht eindeutig wären, wäre die Anforderung in ersten Beitrag nicht stimmig beschrieben.

find sucht ja nur in einem TreeNode.

Nicht wenn man true angibt, wie man das sinnvoller weise machen muss, wenn man keine Ahnung hat, wo der TreeNode sich rumtreibt.

Und wenn ein TreeView auf jeder Ebene nur zehn TreeNodes hätte, hätte er bei ebenfalls überschaubaren sechs Ebenen 1 Million Nodes, ohne unübersichtlich zu sein.

herbivore

Also ich verstehe Chandereggs ersten Satz so, dasser genau weiß, welcher Treenode selektiert ist, und also zu durchsuchen.

Daß Find auch rekursiv kann, habich noch gar nicht gewußt.
finde ich auch nicht sonderlich sinnvoll.
Besser fände ich ein Feature, daß nach Pfaden sucht, wie XPath in Xml.