Click here to Skip to main content
13,053,844 members (61,784 online)
Click here to Skip to main content
Add your own
alternative version


84 bookmarked
Posted 8 Feb 2005

Article One: Building a UI Platform in C# - Drag and Drop

, , 28 Feb 2005
Rate this:
Please Sign up or sign in to vote.
The initial architecture for drag and drop takes flight.

Article Selector <AREA shape=RECT coords=8,52,456,78 href=""><AREA shape=RECT coords=8,82,456,108 href=""><AREA shape=RECT coords=8,112,456,138 href=""><AREA shape=RECT coords=8,142,456,168 href=""><AREA shape=RECT coords=8,172,456,198 href=""><AREA shape=RECT coords=8,202,456,228 href="">


To solve dragging, we need to look very closely at the dragging sequence. First, the mouse is positioned over a control (causing it to go “hot”). Next, the left mouse button is held down. Then, the mouse is moved until some part of the control intersects the drop area. Finally, the left mouse button is released. This is a drag with perfect user procedure. What if the user very energetically clicks the left mouse button, causing the mouse to shift a few pixels before the button is released. Internally this may look like a drag, but it’s really a click. To avoid the problem of inadvertent dragging, we need to debounce the start of the drag. This can be done quite easily by not starting the drag until we have moved a few pixels.

Another scenario: the user begins a drag, but then clicks the right mouse button before dropping. What does this mean? For our purposes, we will interpret a right mouse click as a plea for help. Dragging can be dangerous (have you ever lost a folder in the Windows Explorer?), and to make our user feel comfortable with dragging we need to support their right to cancel the drag at any time. A right-click during a drag does this quite nicely.

The Drag Cycle

Let’s synthesize all of this into a target sequence: the Drag Cycle. The Drag Cycle will consist of:

  • Start (left mouse down and mouse moved more than a few pixels).
  • Drag (mouse moving with left mouse down).
  • End (left mouse up).
  • Cancel (right mouse down while dragging).

In addition to isolating the exact sequence of a drag, we need to recognize the different kinds of dragging. First, we have “factory” dragging, where a copy of the dragged item is made and then moved around in the form until it is dropped. Here the conceptual model for the user is: drag to create something. A second type of drag is the “move” drag, where no copy is made and the item itself moves during the drag. Here we are selling the drag as a way to rearrange items; nothing new is created. Both types of drags should be supported.

ApplicationZero and some tests

From our previous article, we have ApplicationZero:

The solid rectangle can be dragged over the frame and dropped. This is a move drag. Covering the full Drag Cycle, we have these tests:

  1. Position mouse over solid rectangle (goes hot).
  2. Position mouse over frame (nothing happens).
  3. Drag solid rectangle over frame (frame goes hot).
  4. Drag solid rectangle over the frame and drop (solid moves).
  5. Drag one pixel to the left (nothing happens due to debouncing).
  6. Drag one rectangle width to the left (dragging starts).
  7. Drag one rectangle width to the left and right click (dragging is cancelled).
  8. Drag over the frame and right click (dragging is cancelled).

You may have noticed that we have moved incomplete cases from the previous article into this case set. It seemed more appropriate for these cases to appear with the drag test sets.

The drag infrastructure

Enhancing our implementation we have:

  • WindowsForm - a standard System.Windows.Form.
  • ControlSystem – the heart of the platform, routes form events to handling objects.
  • FormOverlay – ancestor for controls which fill the client area of the form.
  • ControlOverlay – ultimate parent for all standard controls, behind all other overlays.
  • DragOverlay – ultimate parent for controls involved in dragging, in front of ControlOverlay.
  • Mouse – uses a HitTester to locate the hot control, calls MouseTrap methods when one exists for the hot control.
  • HitTester – tunnels through the control composite, finding the front-most control.
  • MouseTrap – handles mouse events for a given control.
  • DropSite – defines a target area in the form where compatible DragBots can be dropped.
  • DragBot – defines a source area in the form from which dragging can commence.
  • DragManifest – houses DragBots and DropSites, facilitates dragging.

Drag walk-through

The new ControlSystem class hooks the mouse events of a standard Windows form, calling corresponding methods on Mouse. Mouse uses a HitTester to find the front-most control for a given mouse event. When a control is found, Mouse searches its collection of MouseTraps, looking for a trap which corresponds to the control. If a MouseTrap is found, then the corresponding mouse method is called. This is the basic flow of mouse handling.

Dragging is achieved by creating a DragBot, a DropSite, and adding them to the DragManifest. The DragBot deploys a DragTrap into the Mouse. The DragTrap contains the debounce implementation (it doesn’t start the drag until the mouse has moved more than three pixels with the left mouse down).

For ApplicationZero, a DragBot is created for the solid rectangle and a DropSite is created for the frame. When the DragTrap fires, DragBot begins moving the solid rectangle, checking the DragManifest for any compatible DropSites. The moment the solid rectangle intersects the frame, the manifest returns a DropSite. At this point the DropSite changes the appearance of the frame, indicating a legal drop. If the solid rectangle is dragged away, the DropSite changes the frame back to its “cold” appearance. When the solid rectangle is released over the frame, the DragBot requests a drop location from the DropSite and then positions the solid rectangle accordingly. This creates the “snap-to” effect at the end of the drag.

With this infrastructure in place, the first eight tests now pass:

By creating a different DragBot (FactoryDragBot), we can change the behavior of ApplicationZero to that of a factory drag. Here the solid rectangle is cloned when the drag begins, and the clone is dragged. Tests are easily created for this behavior by copying the move drag tests and changing the declaration of the DragBot. The greens for factory dragging:

Tweaks: Constraining the drag

The most basic of dragging behaviors are now in place. Let’s add one more thing before finishing up: axis-locking. Axis-locking makes it easy to constrain a drag to a vertical or horizontal line. The lock itself does something quite simple: it takes the delta (expressed as a point) of the drag operation and modifies it to conform to some rule. To constrict the drag to a horizontal or vertical line, we simply zero out the X or Y portion of the drag delta. The DragBot is responsible for animating the drag sequence, and seems a pretty good place to install the constraint (which we will call a Tweak.) To install a Tweak we would code this:

MoveDragBot dragBot = new MoveDragBot(solidRectangle);


dragBot.Tweak = new HorizontalDragTweak();

We could design any number of drag tweaks, implementing snap-to type behaviors, etc. For now, let’s stick with vertical and horizontal. Our tests:

  1. MoveDrag with horizontal Tweak.
  2. MoveDrag with vertical Tweak.
  3. FactoryDrag with horizontal Tweak.
  4. FactoryDrag with vertical Tweak.

Just to help us manually check tweaks, we’ll paint a line on the form indicating the valid direction of the drag.

After checking the results of each case, we master, verify and move forward under full green.

We’ll, that’s it for ApplicationZero. In the next article we will use threading to animate these same tests. This technique will help us emulate a "real" user, making all future UI testing more lifelike...

An Aside

As you look over the drag infrastructure, you may be thinking: Is all this really necessary? – It looks like a lot of over-engineering. To this we say: You may be right. Remember, our goal is to create a UI library that allows you to combine elements and create cutting edge UI as necessary. This is a very high goal indeed. As stated in the pioneering Design patterns work, "Designing object-oriented software is hard, and designing reusable object-oriented software is even harder". While this statement could not be more correct, we try to boil down any given approach to structure and strategy. That is, we are either defining something, or we are manipulating something.

When defining structure, we try to declare minimalist ancestors and interfaces in those areas where it is clear that extension will be necessary. Where it is not clear that extension will be necessary, we generally lock it down, as there is always a performance hit for extensibility. When defining strategy, we lean more towards pluggability. Ancestors and interfaces can work well for strategies, but they can also be a real nightmare. This is often due to the timing involved in strategies. A heavy ancestor which does “half” of the work for you, with little pinhole abstract methods that let you do things at "just the right time" seems to break down quickly as the system evolves. For example, see the Tweak class introduced above. We like this class because it is focused in its mission and the ancestor does nothing. When you implement and plug a tweak, you are taking full control. This is how we try to fashion strategy classes.

But again, you may be right. As we move forward, implementing various dragging capabilities, we will see how well this infrastructure holds up.




This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


About the Authors

Tom Ollar
CEO Sagerion, LLC
United States United States
I read About Face by Alan Cooper in 1995 and immediately recognized it as a founding document for the future of software. I also recognized we had a long, long way to go - and yes, even with the advent of iOS, we are still not there yet.

At my company, Sagerion (say-jair-ee-on), we can take a look at your planned or existing software and suggest ways of making it better - lots better. We can develop down-to-the-pixel blueprints showing exactly what our suggestions mean. We can help manage on-going development to make sure the top-notch user-experience we've suggested really does get built. Now, honestly, how often have you ever seen all those things happen?

You may or may not already have great development going on - but what does that matter if you don't have great design driving it?

Feel free to contact me at, I would love to hear about your next ground-breaking project.

Jim Bennett
Founder Sagerion LLC
United States United States
-It is a fresh and free distributed source control system.

You may also be interested in...

Comments and Discussions

GeneralCode Pin
Exenten29-May-06 4:01
memberExenten29-May-06 4:01 
GeneralDiagrams Pin
jterrell28-Feb-05 5:24
memberjterrell28-Feb-05 5:24 
GeneralRe: Diagrams Pin
Tom Ollar28-Feb-05 7:27
memberTom Ollar28-Feb-05 7:27 
GeneralRe: Diagrams Pin
FocusedWolf1-Mar-05 5:40
memberFocusedWolf1-Mar-05 5:40 
GeneralRe: Diagrams Pin
jterrell3-Mar-05 4:38
memberjterrell3-Mar-05 4:38 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.170713.1 | Last Updated 28 Feb 2005
Article Copyright 2005 by Tom Ollar, Jim Bennett
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid