TreeView Drag&Drop wahlweise als Kind einfügen

[Sherlock]

Hidiho,

ich hab da eine klassische TTreeView, die eine nutzerdefinierbare Hierarchie wiedergibt bzw. deren Änderung ermöglicht. Drag&Drop funktioniert zur Zeit gut. Im Drop geschieht im Kern das klassische src.MoveTo(dest, naInsert); . Falls man eine neue Hierarchieebene wünscht, muss man sich derzeit mit einem angehängten Kontextmenü behelfen und einen Untereintrag erzeugen, auf den man dann wiederum den eigentlich in die Ebene zu verschiebenden Eintrag fallen lassen kann.
Ich würde das gerne ändern. Es gibt da eine handvoll Useability- und Entwicklungsfragen, die zu klären sind

• Wie ermögliche ich dem Anwender zwischen dem bisherigen naInsert und dem "neuen" naAddChild zu unterscheiden? Ctrl+Drag? Oder Timer im DragOver (was ich derzeit erfolgreich getestet habe)
• Wie stelle ich diese Unterscheidung, im Baum dar? Irgendwie sollte der künftige Vorfahr-Knoten seine "Erwartung" anzeigen. Für naInsert reicht das Standardverhalten, um zu zeigen, "vor mir wird das verschobene Ding landen". Aber wie signalisiere ich das "als mein Kind wird das verschobene Ding landen"? Mir will da gerade gar nichts einfallen...

Hat einer von Euch da eine Idee, oder sowas bereits umgesetzt?

Sherlock

[Jumpy]

Hallo,

wir haben das seinerzeit glaub ich so gemacht, dass wenn man ein Item auf ein anderes Droped, so wird es als Child eingefügt und wenn man es auf Höhe eines Items ins leere daneben dropt, so wird es als "Geschwisterchen" an der neuen Position eingefügt.

Ich meine mit einem eigenen Cursor der sich je nachdem ändert wurde der Unterschied signalisiert, aber für genauere Info muss ich erst mal nachgucken, geht aber leider erst morgen, da ich gerade unterwegs bin.

[Sherlock]

Hat nicht noch jemand eine Idee? Cursor hört sich ja für die Darstellung nicht schlecht an, ich müsste mal schauen ob ich was hübsches finde. Ich bin noch auf eine dritte Möglichkeit gestoßen, daß Verhalten an sich zu implementieren, in dem man mit GetHitTestInfoAt auf htOnItem, htOnIndent oder htOnRight prüft. Das finde ich aber etwas zu fummelig, habe Grobmotoriker (Mediziner) als Kunden.

Sherlock

[Jumpy]

Zitat von Sherlock:

Ich bin noch auf eine dritte Möglichkeit gestoßen, daß Verhalten an sich zu implementieren, in dem man mit GetHitTestInfoAt auf htOnItem, htOnIndent oder htOnRight prüft. Das finde ich aber etwas zu fummelig, habe Grobmotoriker (Mediziner) als Kunden.
Sherlock

Das ist genau das was ich meinte.

Das Problem was ich mit dem CTRL-Taste gedrückt halten habe, ist das ich es mit Kopieren verbinde, d.h. das dragged child / node wird nicht an die neue Position gezogen, sondern es wird eine Kopie des childs erzeugt und an der gewünschten Stelle eingefügt.
Dieses Verhalten haben wir so (neben dem oben genannten) schon einmal in einem TreeView verwendet und es ist mMn das, was man von "überall" her sonst beim Drag & Drop gewohnt ist, sei es eine Zelle in Excel, eine Datei im Explorer, ...

Die Timer und Warten Geschichte die du oben erwähnt hast verstehe ich so: du verweilst auf einem Node, dieser klappt auf und du kannst den gedraggten Node an der richtigen Position in den ChildNodes des gerade geöffneten Nodes einfügen. Falls dem so ist, sehe ich neben der Wartzezeit das Problem dann, wenn der Node auf den du draggst noch keine Childnodes hat und nicht aufklappen kann.

[Sherlock]

Ich finde ja das Verhalten des (Datei)Explorers ganz schön, wenn man eine Datei auf einen Ordner zieht, der Unterordner hat, wird der nach einer kurzen Zeit aufgeklappt, damit man dort aussuchen kann.
Aber ich versuche zusammen mit aussagekräftigen Cursorn mal die Variante mit den HitTests. Mal schauen wie sich das anfühlt. Danke, Jumpy.

Das mit dem Timer hast du genau richtig verstanden, und mein Problem dabei auch erkannt.

Sherlock

[himitsu]

Zitat:

Das Problem was ich mit dem CTRL-Taste gedrückt halten habe, ist das ich es mit Kopieren verbinde

Ich nicht, bzw. er könnte ja Shift verwenden.

D&D + Strg = immer kopieren
D&D + Shift = immer verschieben
D&D + Strg + Shift = immer verlinken

immer ... ohne Strg/Shift wird ein Standardverhalten verwendet, aus den obrigen Optionen, welches kontextabhängig sein kann (siehe Exploerer und Verschieben innerhalb einer Partition oder in eine Andere)

[Sherlock]

Also ich könnte mich mit der HitTest-Methode anfreunden, wenn ich das mit den Cursorn hinbekäme. Kurzer Denkanstoß, bitte. Ich dachte OnDragOver wäre das Richtige Event, um den Cursor abhängig vom HitTest zu setzen, aber er bleibt immer crDrag Scheint, als würde das Accept den Cursor bestimmen und sonst nichts . Insofern dürfte MouseMove auch nicht wirklich etwas bringen. Grml...

Sherlock

[Dejan Vu]

Imitiere doch das Verhalten des Explorers, d.h. Du rufst von dem Knoten der als Vater-kandidat fürs droppen in Frage kommt (GetHitTestInfoAt) dann einfach 'Expand' auf. Und wenn der noch keine Kinder hat, dann fügst Du an dem Knoten, nach einer kurzen Wartezeit einen Dummyeintrag ein und rufst Dann Expand auf. Der Dummyeintrag sieht so aus wie das, was Du da droppen willst... Wenn der Cursor dann weiter bewegt wird, schmeisst Du den Dummyeintrag wieder raus. und rufst für den Knoten, denn Du im Rahmen der Drag-Operation ein Expand aufrufen musstest, eben wieder collapse auf. Das ist zwar Wurschtelkram mit listen ('expanded', 'dummyEntries'), die man pflegen muss, aber es sollte funktionieren. Kann höchstens sein, das das schrottig aussieht.

[Aviator]

Oder einfach den VirtualTreeView benutzen. Der bringt schon sehr viele Funktionen von Haus aus mit und man kann trotzdem noch alles steuern/verbieten oder sonstwas. Noch dazu unterstützt er OLE Drag&Drop und normales VCL Drag&Drop. Und den Aufklappmechanismus hat der Tree meines Wissens nach auch. (Kann man glaube ich sogar einstellen, wie der reagieren soll)

[Jumpy]

Bzgl. Cursor bei Drag & Drop hab ich mich seinerzeit hier schlau gemacht. Vielleicht hilft dir das Kapitel über "Customising the Drag Cursor" ja weiter:

http://www.blong.com/Conferences/Bor...stomComponents