LCL Drag Drop/fr
│
English (en) │
français (fr) │
русский (ru) │
Guide de DoDi pour glisser(drag), déplacer(drop), déposer(Dock)
Les contrôles dans un GUI peut être attrapée avec la souris, déplacés vers d'autres endroits, et déposés par dessus d'autres contrôles ou sur le bureau. Lorsque le contrôle glissé est déplacé vers un emplacement différent, l'opération est appelée "glisser déposer". Par ailleurs, le contrôle source et le contrôle cible peuvent échanger des informations ou interagir de toute autre manière, ce qu'on appelle une opération de "glisser-déposer".
Mais tout cela ne fonctionne pas de lui-même, une application doit configurer les opérations permises de sorte que la bibliothèque LCL puisse savoir ce qu'il faut faire avec chaque contrôle simple dans un GUI. Les opérations sophistiquées exigent davantage de code pour la gestion du retour visuel à l'utilisateur de l'application, et ce qui va se passer quand le contrôle glissé sera finalement déposé.
Glisser Déplacer
C'est seulement une action de glisser simple et originale. Les acteurs sont:
- Un contrôle d'origine que l'on peut glisser dans le GUI
- Un objet qui glisse, dérivés de TDragObject
- des fonctions d'aide
- des événements
Maintenant, jetons un œil à la manière dont ils travaillent ensemble, basé sur l'implémentation initiale en Delphi pour plus de clarté. L'implémentation de la bibliothèque LCL est quelque peu différente dans l'utilisation des objets d'aide, les détails seront discutés plus loin.
La source de glissement
Un contrôle peut être rendu déplaçable en fixant sa propriété DragMode à dmAutomatic. Lorsque l'utilisateur appuie avec le bouton gauche de la souris sur un tel contrôle, le pointeur de la souris change en un indicateur de glissement jusqu'à ce que l'utilisateur relâche le bouton, ou annule l'opération en appuyant sur la touche Escape. L'indicateur suit désormais les mouvements de la souris et change sa forme, conformément à ce qui se passera lorsque le contrôle sera déplacé sur l'emplacement du moment.
Le glissement peut également être lancé dans le code, en appelant la source.BeginDrag. Dans les deux cas, la procédure d'aide DragInitControl est appelé pour démarrer le glissement. Le contrôle initial lève un évènement StartDrag, là où l'application peut fournir un objet de glissement usuel. En cas d'absence d'un tel objet, un objet par défaut est créé. Des structures de données internes pour la rétroaction visuelle et plus sont initialisées. Alors DragTo et appelée pour montrer que le glissement a commencé.
L'objet qui glisse
A drag object receives all user input while dragging. In the default implementation it reacts by calling either DragTo or finally DragDone.
The drag object also is responsible for the visual feedback:
- GetDragCursor returns the mouse pointer shape.
- GetDragImages returns a list of drag images, to be attached to the mouse pointer.
- ShowDragImage and HideDragImage implement the visual feedback.
The Finished method notifies the source control when dragging stops. In case of a cancel'd operation it invokes source.DragCanceled, followed by source.DoEndDrag in either case, which raises an EndDrag event.
LCL Modifications
The current LCL implementation has removed input processing from the drag object, so that the application can no more customize the UI. And the LCL implementation is far from being okay :-(
Also the drag object is bypassed in the presentation of the visual feedback.
Helper Functions
Helper functions primarily allow for access to protected properties and methods of the controls and other classes, from outside the Controls unit. They also can perform common tasks, and can encapsulate platform specific and other implementation details.
General Helpers
DragTo determines the current drag target, sends notifications to the involved controls, and manages the visual feedback. It also handles the delayed start of a dragging operation, i.e. can wait for the mouse moving away far enough from the starting point.
DragDone terminates dragging, either with a drop or cancel of the operation.
CancelDrag is protected against false calls, otherwise it defers further actions to DragDone.
Special Helpers
Some more public helper procedures exist, which are undocumented in Delphi and are not required for customized dragging operations.
DragFindWindow searches for a drag target window (platform specific).
DragInit initializes the internal management, like mouse capture, and the visual feedback.
DragInitControl creates the drag object, then calls DragInit.
SetCaptureControl handles the mouse capture.
Events
OnStartDrag/Dock
This event occurs when the operation starts. The handler can provide a custom DockObject for the operation.
OnDrag/DockOver
This event notifies a possible target, when an object is dragged over it. The handler can signal to accept or reject an drop.
The event signals not only mouse moves, but also when the mouse enters or leaves a target control.
An OnDockOver event occurs on the DockSite, not on the target control under the mouse. The handler can signal to deny an drop, and can adjust the visual feedback. The event occurs when the mouse enters or leaves a control, and with every single movement of the mouse.
OnDrag/DockDrop
This event notifies the target control of the end of a drag operation.
OnEndDrag/Dock
This event notifies the source control of the end of a drag operation.
Docking specific Events
(this section should be moved to docking topic)
OnGetSiteInfo
This event occurs during the search for a qualifying dock site. Multiple dock sites can overlap each other, reside in overlapping windows, or can be invisible. Every candidate must supply an influence rectangle (catching area), and can signal to reject an drop. The drag manager selects the most appropriate dock site as the target for subsequent OnDockOver events.
OnUnDock
This event occurs when the dragged control has to be removed from its host dock site.
It's unclear what should happen when the handler denies to undock the control.
LCL Implementation
The Delphi implementation of dragging has many flaws, in detail with regards to docking. Until now nobody seems to understand the details of the Delphi dragging model, most code was copied from the VCL and consequently implements exactly the same misbehaviour. This section, and more important the docking specific page, shall shed some light on the dragging model in general and the severe design and implementation flaws in the Delphi implementation.
The current LCL implementation uses a DragManager object and drag/dock performers instead of helper functions. The reason for this breaking change is unclear - who can explain?
While the Delphi model must be provided for compatibility reasons, the introduction of a DragManager class and object (singleton) allows for the implementation of an alternative drag manager, with improved behaviour, and allows an application to select the most appropriate manager.
DragManager
This object handles the captured input, provides helper methods, and stores dragging and docking parameters.
It's questionable whether the drag object shall not be allowed to handle user input. It makes the system safer, but disallows applications to extend the user interface for specific dragging operations.
The helper methods require different calls, but this is harmless as long as they are only called from LCL components.
More critical is the storage of dragging parameters in the DragManager object, which vanish when a different drag manager is installed. This is fatal in case of the list of registered dock sites :-(
Drag Performers
The internal use of different classes for dragging and docking is okay in so far, as the procedures differ significantly between drag-drop and drag-dock operations. Nonetheless common actions should use common code, e.g. inherited from the common base class.
Message Sequence Chart or UML Sequence Diagram
Provided by Tom Verhoeff
Something along the lines (this is for Delphi; view with monospaced font):
Main Drag (Optional) Drag
User Event Source Drag Target
(Mouse) Loop Control Object Control
= = = =
| | | |
1|--MouseDown--->| | |
| 2#--OnMouseDown->| |
| | 3# |
| 4#<-BeginDrag()--# |
| # # |
| | | |
| 5#--OnStartDrag->| |
| # 6#----Create---->= |
| | # | |
7|--MouseMove--->| | | |
| 8#-----------------------------------OnDragOver->|
| # | | 9#
| # | | #
| | | | |
10|---MouseUp---->| | | |
| 11#-----------------------------------OnDragDrop->|
| # | | 12#
| # | | #
| #---OnEndDrag-->| | |
| | 13#----Destroy--->= |
| | | |
The DragObject is optional. There could be multiple candidate targets.
The Main Event Loop determines which event to send to which object,
depending on the user action, the cursor location, and the current state
of the GUI.
4 somehow triggers 5 (there is a delay depending on the Boolean parameter Immediate to BeginDrag).
6 determines the location of the MouseDown and may use this to decide on what gets dragged (through GetCursorPos, ScreenToClient, MouseToCell). It can call SetDragImage to visualize a thing being dragged.
The chain 7, 8, 9 can occur repeatedly; 9 indicates acceptability of a drop at this target via the Boolean var parameter Accepted.
12 is called only if the immediately preceding OnDragOver of this target returned Accepted = True; i.e. Accepted is a precondition of 12.
13 receives the parameter Target to know where the drop was accepted; if Target = nil, then the drop was cancelled by the user (MouseUp at an unacceptable location), and OnDragDrop was not performed; if Target <> nil, then OnDragDrop was already performed at the Target. The work associated with an actual drop is thus divided over the OnDragDrop (for actions at the target) and OnEndDrag (for actions at the source). Since a Drag Object needs to be destroyed, independent of whether the drop was successful or canceled, it is best to call Free (or Destroy) only in the OnEndDrag handler.
Only one drag can be active at any moment; it either ends in a drop or is canceled.
There are various other things to be included, but this is the fundamental part. (Maybe also see Delphi-Central or "Implementing drag-and-drop in controls".)
I hope this is helpful. Tom
