The AGT (Argentum Tela) series of articles is an effort to do two things.  Usually an idea is presented only in its finished form.  The first goal is to do some Reality Blogging, to show an idea evolve over time without pulling any punches.  The second goal, and the example vehicle for the evolution aspect, is an extensible design-time environment similar to what we have in Visual Studio 2008.  This type of application has all sorts of interesting uses.  My example is a Home Theater layout tool.  Read the entire saga: http://www.damonpayne.com/2008/09/14/RunTimeIsDesignTimeForAGT0.aspx

Designer surface interactions

My goal now is to actually start thinking about creating and designing things.  The preferred means of using this is as follows:

1.       From the toolbox I start dragging something out towards the Great Wide Open.

2.       Somehow visually indicate that I am dragging something.

3.       When I let go, see where I have dropped what I was dragging.

4.       If what I dropped upon was something that cares about being dropped on, do something useful like create a design-time representation of the thinger.

Some “improved” traffic patterns downtown where I work has left me with a lot of time to think about design interactions on my way home every day.  As I’m coming to expect, every single thing related to Drag ‘n drop in WPF or WinForms is not in Silverlight, but we can start defining some constructs of our own.  I’m adding a Design Solution Folder, within which will be a StarUML project.  Sometimes it’s better to explain using pictures.

1.       IToolboxService should use IDragDropManager to indicate that Drag operation is beginning.

2.       IDragDropManager will query the IToolboxService to determine what is the type of the dragging item.

3.       IDragDropManager will use IDragTypeCreator to build some type of visual representation to indicate where the dragging item is.  It will attach some events to this Control and place it as a child of the RootVisal of the IRgeionManager, in the front of the Z-order.

4.       The end of a drag/drop will be determined by the events attached to the Control, such as Left mouse button up.

5.       IDragDropManager will query all the IDropTarget instances registered with it.  If the Location of the where the dragging Control was dropped falls within the Bounds of one, it will call that instances OnDrop event with the original ToolboxItem.  This allows the IDropTarget to do whatever it wants using the original information.  Otherwise, the drag representation will be destroyed by IDragDropManager.

6.       In our case, if we successfully drop on top of the visual representation of a DesignSurface instance, DesignSurface will use IDesignTypeCreator to create the final design-time representation of the IDesignableControl.  This allows different visuals and behaviors to be attached such as adorners for resizing and registration with various other design-time services.

I am nearly certain I am going to have to change RootVisual of IRegionManager to be a Panel rather than UIElement.  UIElement has no “children” collection for me to use for my drag-representation.  Based on some things I want to support later (alignment snap lines, possible extra adorners) the DesignSurface is ultimately going to have to be a base type or implement some kind of interface with some kind of collection of “filters” or IDesignSurfaceBehavior implementations.

The source code as of the end of this article contains stubbed out unfunctional versions of the interfaces mentioned here. In the next article, we’ll actually try to drag/drop around a purple couch.  After that we’ll spend some time doing code refactoring (the TODO are building up) and some visual refactoring before moving on to more complex interactions.

Source code: DamonPayne.AGT[6].zip (598.45 KB)