Suchergebnisse

primitiv-Sample, wie anwendungsübergreifendes DragnDrop umsetzbar ist: VB.NET-Quellcode (36 Zeilen) Vorraussetzung, dass ühaupt auf ein Control gedropt werden kann, ist, dass seine Control.AllowDrop - Property auf True eingestellt ist (ist hier im FormDesigner erledigt, geht aber auch per Code) Wichtig ist v.a. das Verständnis des DataObjects, das in den EventArgs angeliefert wird. Ein DataObject enthält die Daten, zuzüglich Informationen über den Datentyp. Es kann "dieselben" Daten in verschied…

Zitat von ~blaze~: „Nicht jedes IDataObject ist gleichzeitig ein DataObject.“ In meiner Praxis ists noch nie vorgekommen, dass das IDataObject nicht ein Windows.Forms.DataObject war.

Zitat: „Du kannst aber auch eigene Klasse von IDataObject ableiten“Du meinst: Implementieren. Das ist immerhin eine theoretische Möglichkeit, und wollte ich auch gleich ausprobieren:VB.NET-Quellcode (28 Zeilen)Allerdings sehe ich mich außerstande, all diese von IDataObject geforderten Methoden-Stubs sinnvoll auszufüllen. In .Net würde auch niemand so programmieren, sondern stattdessen vom Forms.DataObject erben (und damit das ganze Gedöhns), statt es selbst zu implementieren. Ich empfehle dennoc…

Bisher wurde ja nur gezeigt, wie Listbox und Textbox einzurichten sind, will man aus beliebiger Anwendung heraus was drauf droppen. Jetzt aber wird die Listbox zusätzlich als Quelle von D&D eingerichtet. An Funktionalität verlangt dieses:- Der Drag-Vorgang ist zu starten, wenn mit gedrückter Maustaste ein kleines Stück gezogen wurde. Das ist wichtig, damit nicht bei jedem MouseDown ein D&D-Vorgang startet, denn MousDown ereignet sich ja auch bei Klick und Doppelklick, wenn also D&D garnet gemein…

Draggen innerhalb der Anwendung ist eine sehr andere Baustelle. Genau genommen ists ein FehlDesign, dass DiA mit derselben DoDragDrop()-Methode gestartet werden muss wie anwendungsübergreifendes Dragging. Diese Methode erzwingt die Angabe eines DataObjekts, was ganzngar unnötig ist, und jedermann denken macht (und programmieren), dass beim DiA Daten von einem Ort zum anderen zu transportieren seien. Dem ist nämlich nicht so. Da beim DiA so gut wie immer sowohl Start- als auch Ziel-Control bekann…

Ja, obiges hübsches Sample hat den gravierenden Nachteil, dass der Ziel-Bereich nur ungenügend highlighted wird: Soll nämlich auf oberster Treeview-Ebene eingehängt werden, so kann kein Ziel-Node selectiert werden. Ausserdem löst das Verstellen der Selection natürlich das Treeview.AfterSelect-Event aus, an welches in anspruchsvollen Oberflächen meist weitere umfangreiche Funktionalität angehängt ist. Das wird ganz schön rumklappern, wenn der User über verschiedene Nodes fährt. Daher muss ein own…

Tja, diese LösungB für Draggen innerhalb der Anwendung (DiA) fällt aber qualitativ um einiges hinter der in post#9 vorgestellten LösungA zurück: 1. LösungB startet beim MouseDown sofort den Drag-Vorgang. Das entspricht nicht der üblichen und sinnvollen Maus-Geste zum Starten eines Drag-Vorgangs: Man muss nämlich mit gehaltener Taste erst ein paar Pixel ziehen. Ohne diese Zusatzbedingung kommt es zu zuvielen (abgebrochenden) Drag-Vorgängen, und vor allem zu Konflikten, wenn man das MouseDown-Even…