Node eindeutig identifizieren, JvPageListTreeView

[Namenloser]

Zitat von haentschman:

- nach Text suchen fand ich auch zu unflexibel, wenn sich die Texte im Tree mal ändern sollten.

Du kannst das aber flexibel halten, indem du nicht den Text vergleichst, sondern die Eigenschaft Data. Enwteder indem du ein Objekt darin speicherst (was für mich so immer am einfachsten war), oder eine eindeutige Nummer (was alzaimar meint).

[haentschman]

Guten Morgen...

Zitat:

Du kannst das aber flexibel halten, indem du nicht den Text vergleichst, sondern die Eigenschaft Data.

- auch eine Variante

Danke an alle...

[alzaimar]

Zitat von haentschman:

hmmm... irgendwie habe ich das Gefühl daß wir uns mißverstehen.

Nicht 'wir uns', sondern 'Du mich'.

Zitat von haentschman:

...dümmlich ist nur, daß man an die Data Eigenschaft nur dran kommt, wenn man den Index des Knotens kennt.

Delphi-Quellcode:

Function IndexOfNode(aDataContents : Integer) : Integer;
Begin
  For Result:=0 to TreeView.Nodes.Count-1 do
    If Integer (TreeView.Nodes[Result].Data) = aDataContents Then
      Exit;
  Result := -1
End;

So bekommst Du dann den Index des Knotens. Also nix mit '...dümmlich..'
Du deklarierst deine ID als Konstanten, z.B.

Delphi-Quellcode:

Const
  IDDatenbankSeite = 0;
  IDBenutzereinstellungen = 1;
  ...

Dann fügst Du die Knoten in deinen Baum ein, wobei Du der 'Data'-Eigenschaft die ID-Konstanten zuweist.
Auf einen konkreten Knoten (z.B. den mit den Benutzereinstellungen) greifst Du dann so zu:
TreeView.Nodes[IndexOfNode(IDBenutzereinstellungen)].Selected := True Wenn Dir das zu blöd ist, merkst Du Dir die Indizes der einzelnen ID-Konstanten. Allerdings musst Du die dann bei Änderungen an der Baumstruktur erneut zuweisen:

Delphi-Quellcode:

Var
  idxDatenbankseite,
  idxBenutzereinstellungen : Integer;
...
  idxDatenbankseite := IndexOfNode(IDDatenbankSeite);
  idxBenutzereinstellungen := IndexOfMode(IDBenutzereinstellungen);
...
  TreeView.Nodes[idxBenutzereinstellungen].Selected := True

Übrigens hätte ich als Anwender ein Riesenproblem damit, das sich die Reihenfolge des Baumes ändert, wenn neue Eigenschaftsseiten hinzukommen. Anwender bevorzugen kleiche *Positionen* von Dingen als wenn sie in einer sortierten Liste jedesmal suchen müssen. Du hättest in unterschiedlichen Sprachen auch ein unterschiedliches Layout. Toll für den, der deine Anwendung in beiden Sprachen bedienen muss.

Obige vorgeschlagene Trennung von Position und Identifikation bleibt jedoch hiervon unberührt, da es die klar robustere Implementierung ggü. fest verdrahteten Index-Konstanten ist.

[haentschman]

Danke für Deine Zeit... 8)

...klar das Dein Code funktioniert
...aber das ganze ist viel simpler...siehe Bild

- ich benutze ein JvPageListTreeView in Verbindung mit JvPageList.
- jeder Knoten im Tree ist "verlinkt" mit einer Page aus der JvPageList (Designzeit)...(wie PageControl nur ohne Reiter)
- der Tree verändert sich wenn überhaupt nur zur Designzeit
- wenn der Tree auch zur Laufzeit Veränderungen hätte, müßte man selbstverständlich mehr Aufwand betreiben.
- der Tree ist einfach nur eine Liste und nicht kompliziert "verknotet"
- da sich der Tree eigentlich nicht verändert fand ich das Durchsuchen der Nodes jedesmal zur Laufzeit etwas übertrieben.
- mir ging es im wesentlichen um die Wartbarkeit des Codes bei Veränderungen / Ergänzungen des Tree´s

PS: mit dem "dümmlich" meinte ich den Direktzugriff auf die Eigenschaft. Mit einem Schleifendurchlauf durch alle Nodes ist klar, daß man den Index bzw. die Eigenschaften des Nodes auswerten kann.

Zitat:

Du hättest in unterschiedlichen Sprachen auch ein unterschiedliches Layout.

...ist korrekt, aber da die Software durch die implementierten Formulare und gesetzlichen Regelungen nur in Deutschland Verwendung findet und nur in Deutsch verfügbar ist, ist dieser Punkt eher zu vernachlässigen

Zitat:

Übrigens hätte ich als Anwender ein Riesenproblem damit, das sich die Reihenfolge des Baumes ändert, wenn neue Eigenschaftsseiten hinzukommen. Anwender bevorzugen kleiche *Positionen* von Dingen als wenn sie in einer sortierten Liste jedesmal suchen müssen.

ich glaube da streiten sich die Gelehrten. Mir persönlich ist die sortierte Liste lieber, da ich anhand dessen was ich suche nach "oben" oder "weiter runter" blättern muß.

Ich wünsche Dir frohe Feiertage...

verkehrtes Bild...

[alzaimar]

Ich kenne dieses Paradigma. Ich würde jedoch versuchen, die Eigenschaftsseiten zu gruppieren, also eine Art Hierarchie hereinzubringen. Dann wird das übersichtlicher.
Betrieb
-- Allgemeine Einstellungen
-- Programmstart
-- Datenbank
Filter
-- Filterarten
-- Filtergrößen
-- Filterqualitäten
...

Bei der Frage, was sich ein Anwender eher merkt, streiten sich die Gelehrten übrigens nicht: Positionen erkennen und merken kann sich der Mensch schon seit Jahrmillionen, Lesen erst seit ein paar hundert Jahren. Bei der Ergonomie sollten Instinkte berücksichtigt werden, kognitive Fähigkeiten eher nicht. Dann wird ein Dialog als 'einfach', 'übersichtlich' und 'nicht überladen' angesehen.

Wenn Du schon Paradigmenwechsel beim Eingabedialog (überladene Pagecontrol => strukturierte Treeview) durchführst, solltest Du konsequent sein, und ihn auch bis zum Ende durchziehen (und nicht auf halbem Wege stehenbleiben). Großartig übersichtlicher dein Dialog so ja auch nicht, denn Du stellst ja nur die Tabs anders dar.

Solche Eigenschaftsdialoge (ob nun hierarchisch oder nicht) habe ich auch zur Genüge implementiert. Ich verwende mittlerweile die von mir beschriebene Implementierung, da bei der Weiterentwicklung immer wieder neue Eigenschaftsseiten hinzukommen. Ich gruppiere auch um, sodaß sich die Indexe während der Entwicklung ständig ändern. Mit der Trennung habe ich nun keine Probleme mehr. Allerdings hänge ich in die Data-Eigenschaft das TabSheet in in dessen Tag-Eigenschaft meine ID. So kann ich beim Wechsel im Baum das entsprechende Tab anzeigen und finde gleichzeitig den richtigen Knoten zu einem Tab. Ich habe z.B. in meinen Datenbank-Dialogen grundsätzlich einen Knopf "Einstellungen". Wenn man den drückt, kommt der Eigenschaftsdialog hoch, wobei gleich die 'Datenbank'-Seite ausgewählt ist.

Zitat von haentschman:

- wenn der Tree auch zur Laufzeit Veränderungen hätte, müßte man selbstverständlich mehr Aufwand betreiben.

Aus deinem anderen Thread

Zitat von haentschman:

...einige Einstellungen dürfen nur verfügbar sein, wenn eine Datenbankverbindung besteht...

Ja, wat denn nu? Oder gehts nicht um diesen Dialog?

[haentschman]

Zitat:

Ich würde jedoch versuchen, die Eigenschaftsseiten zu gruppieren

...hast Recht...ich mach mich dann mal an die Arbeit

Zitat:

Ja, wat denn nu?

...ähmmm
- es gibt im Prinzip 2 Versionen des Tree´s (visuell) mit und ohne Datenbankverbindung
- es ist zwar nicht die feine englische Art aber um mir das Neuaufbauen des Tree´s zu ersparen habe ich die 2 Versionen des Tree´s übereinander gelegt und je nach Status ist der eine oder der andere Visible.

PS: an deinem Beispiel kann man deutlich sehen, daß die Icons im Tree das ganze optisch auch auflockern.

...bis später.

[edit]
...ist´s so besser ?
...siehe Bild

PS:
- die 5 da oben ist der derzeitige AbsolutIndex des gewählten Knotens...Information für mich 8)
- die Breite ist so ok, da es Einstellungen gibt, welche die gesamte Breite beanspruchen. (Bild2)
[/edit]