Monday, June 15, 2009

Who Manages Docking?

The default (unmanaged) Delphi behaviour drops a control into a docksite as is, at the current position. This mode can be used e.g. in designers (CAD...), where a control is selected and placed on a drawing surface.

Docking managers will organize the layout of a docksite, usually by filling the entire site with the dropped controls (tiling).

Other docksites can implement their own docking, as e.g. a sophisticated version of beforementioned designers. They also can implement docking of pages in a TPageControl, and provide tabs for every dropped page.

What's essential for these various docking models?

The interaction between the dragmanager and the source and target controls occurs in dsDrag... messages. dsDragEnter and dsDragLeave notify the target site, when the dragged control enters or leaves the docksite's area. A site can prepare for an eventual drop, signal preferred locations to the user, or whatever may be desireable. dsDragMove then shall determine an concrete docking place and provide visual feedback, by modifications to the cursor and the docking rectangle. Like in drag-drop, a non-accepting situation should be signaled clearly.

On a drop the docksite receives another dsDragLeave, so that it can be reset into "normal" (inactive) mode. Then the control is dropped and can be placed according to the information in the dockobject, resulting from the last dsDragMove. In ManualDock no dsDragMove occurs, so that all information must be filled into the dockobject before. The required information can differ widely, depending on the docksite management. The standard DropOnControl and DropAlign are applicable almost only to tree-docking, worthless in unmanaged docking.

The docking information should be handled by the site manager, i.e. either by DockManager, or in the overridden methods of a specialized docksite (TWinControl). The DragManager only has to determine the target site, send the drag messages to it, and then let the dockobject do the visual feedback. Please note that not only the docksite can be designed freely, it also can provide special docking objects, which can contain any additional information for special site layouts and feedback. We already have such cases, e.g. the anchored docking doesn't fit into the tree docking model, because it deserves more and different information. Therefore the DockObject should be passed to the target site, and from there to the DockManager (if used), instead of the mostly useless tree docking information. This way the site and the DockManager have full control over the information in the DockObject.

Unless we agree about some special default (unmanaged) behaviour, different from the Delphi model, the involved docksites and controls should do nothing themselves. They either pass the drag messages to their DockManager, or to the user provided message handlers. If neither is present, only the floating rectangle has to be moved.

The DragManager only has to distinguish between drag-drop and drag-dock in the determination of the drop target. This can be done in the different drag- and dock-objects, as currently is done in the drag performers. IMO such performers are not needed at all, because they cannot know what a special docksite or docking objects have implemented.

No comments:

Post a Comment