CTreeCtrl Nummer des selektierten Eintrages

RML

Hallo,
ich habe ein CTreeCtrl erstellt. Mir ist klar, wie ich den Namen des Eintrages, der selektiert ist, herausfinden kann. Das hilft mir aber nicht unbedingt weiter, da in dem tree verschiedene Objekte aufgelistet werden, die aber u.U. den gleichen Namen tragen können.

ich habe mir also überlegt, in jedem objekt eine variable zu speichern, die die nummer des Objektes im tree enthält. (die nummer wird natürlich bei veränderungen korrigiert.)

wenn ich nun also ein objekt selektiere. wie finde ich denn heraus, der wievielte eintrag das ist ?

ich steh hier mal wieder total auf dem schlauch (owohl es bestimmt total einfach ist).

habt ihr einen tip für mich ?

gruß
aus berlin

peterchen

Mittels SetItemData / GetItemData läßt sich jedem tree-Item eine DWORD zuordnen. dort kann man z.B. einen ID oder (wenn man aufpaßt) einen Zeiger speichern.

RML

hi,
das ist zwar genau der umgekehrte, weg, aber auch eine idee.
ich werd mir das mal anschauen.
danke erstmal

alex-t

wenn du nur eine indizierung des baumes benötigst wirst du mit einer angepassten such-/auflistungsfunktion besser weiterkommen, als mit hilfe von zusatzinformationen innerhalb der items. dies gilt insbesondere für den fall, dass ein oder mehrere items childitems besitzen.

mit integerwerten wird die indizierung im letzten fall nicht sauber lösbar sein.

hier ein tipp:

msdn schrieb:

GetRootItem

msdn schrieb:

GetNextItem

damit kannst du eine schleife basteln die den ganzen baum durchläuft.

ausserdem kannst du mit dieser variante auch childtrees indizieren.
dafür brauchst du:

msdn schrieb:

ItemHasChildren

hoffe du kannst damit etwas anfangen.

Shlo

eine Schleife die jedes Mal den ganzen Tree durchläuft ist totaler Blödsinn. In diesem Fall würde ich eine Map nehmen, HTREEITEM als Schlüssel und eine eine selbstdefinierte Struktur als Argument. GetItemData und SetItemData ist eine altmodische Variante.

peterchen

GetItemData und SetItemData ist eine altmodische Variante

Hä?

Eine generische Lösung wäre eine bidirektionale map, da man das Mapping oft in beide Richtungen braucht (nach meiner Erfahrung ist aber Tree --> Data ungleich häufiger)

Designziele sollten sein:
a) Die Daten des Nutzerinterfaces (HTREEITEM) aus den "eigentlichen" Daten rauszuhalten.
b) Wenn die Daten sich häufig bzw. hinter dem "Rücken" des Trees ändern, sollte man die Synchronisation (Daten <--> Darstellung) möglichst zentral halten und vor allem von den Datenänderungen entkoppeln (d.h. Daß man nicth bei jeder Datenänderung daran denken muß, den tree zu informieren, jetzt mal Bitte den Item 17 zu löschen usw.) Das ist beim TreeCtrl leider nicht so einfach.

Ob es "totaler Blödsinn" ist, linear in dem treeCtrl zu suchen, hängt von verschiedenen Faktoren ab. Immerhin bieten ItemData + Suche das benötigte bidirektionale Mapping, ohne das man zusätzliche Datenstrukturen einführen muß. Auch ein Vorteil.

alex-t

RML schrieb:

...

wenn ich nun also ein objekt selektiere. wie finde ich denn heraus, der wievielte eintrag das ist ?

...

also hört mal, wie kommts eigentlich, dass man nach einigen antworten nicht mehr auf die frage eine antwort sucht, sondern einfach den anderen aussticht?

ich habe meinen lösungsvorschlag darauf bezogen, dass man diese information vielleicht nicht sehr oft benötigt und dass der baum zwar aus beliebig vielen teilbäumen besteht, aber trotzdem nicht zu gross ist.

diesen fall hatte ich zumindest in meinem tree, der allerdings als eine art menü in meiner anwendung dient. und es funktioniert wunderbar.

heirzu muss ich dich fragen, wie du teilbäume handhaben willst?

RML

so, ich hab mal etwas rumgetestet.

die variante mit "get- und setitemdata" scheint zu klappen.

diese variante nimmt mir sogar einigen verwaltungsaufwand bei den datensätzen ab, da ich sonst zusätzlich zu meiner datensatz id auch noch die ständig wechselnde nummer im tree als zusätzliche variable in jedem datensatz verwalten müsste. allerdings hab ich das bisher nur bei solchen einträgen probiert, die keine childs sind. aber ich glaube, das macht keinen unterschied. ihr habe mir jedenfalls sehr geholfen (ob klein oder grosser tree, weiss ich nicht, da es ja vom benutzer abhängt, ob er 10000 oder nur 1 datensatz braucht...)

danke!