The ways users have been able to interact with controls on the designer has steadily been evolving. With ActiveX controls in VB 6, users were simply presented with a rectangular region they could click and drag. Grab handles were provided entirely by the designer and were not customizable by the controls. The only mechanism control authors had were “verbs”, which were commands that appeared on the context menu for a control.

Windows Forms 1.0 slightly improved this by giving control authors a design time “paint” event that was called after their control painted. This event allowed a control author to draw additional design time UI on the surface of the control, but all user interaction with that UI had to be done by hand. Windows Forms 2.0 greatly improved this model with an object called the Behavior Service. The behavior service allowed a control designer to add a “behavior” onto a stack of behaviors. A behavior was a hook into all mouse, keyboard and menu command input and could also provide lightweight UI objects called “glyphs” that would float on top of the controls on the design surface. The behavior service enabled us to create some cool features in the Windows Forms designer like snap lines and smart tags.

It's time for my second post on Cider's design time architecture. Last time I introduced the editing context and described how services and context items work. It's now time to talk about how we're going to do extensibility in Cider. Before I can do that I need to explain what I mean when I talk about an extensible design time architecture. Then, I need to give you a little background on how Windows Forms implements their extensibility, and finally I can start to describe how we do it in Cider and why we chose to do things differently.

Design Time Extensibility

In the good old days of ActiveX controls, designers weren't very extensible. The property window for VB 6, for example, was hard-wired through the magic of OLE Automation to know about exactly four data types: fonts, colors, enums and variants. The VB 6 designer treated all controls as opaque rectangles. As long as your custom control could fit into these four data types and be treated as a rectangle that could be placed and sized in X-Y coordinates, you were happy. The introduction of Windows Forms required that we re-think some of this. For example, the .NET Framework introduced many new data types. Having a property window that only understood a limited set of data types would have made learning the increased depth of Windows Forms much more difficult. Also, Windows Forms introduced concepts like pluggable control layouts, so assuming all controls fit a standard rectangular X-Y model would have been a big compromise.

Didn't get your XBox 360 and now you're left with nothing to do during the holidays? If so, why not try out the December CTP of WinFX? We've got a little treat for you: Starting with this CTP you can also download the Cider Visual Designer for WPF. That's right, we managed to get some very early bits of Cider folded into the December CTP because, well, pretty much everyone is tired of writing XAML.

Now, don't set your hopes too high. Cider is a long way from shipping, and it is a long way from being the great tool we expect it to be. This release of Cider supports very basic functionality associated with creating a WPF Form, adding simple controls to the form, moving and sizing them, and setting properties on the controls. At this early stage, the designer is not sufficient to create WPF applications without the developer also manipulating XAML. If you are building WPF applications, you are accustomed to XAML, and the designer can really help you out. Not only will it augment your experience by allowing a "preview" scenario for your markup and by providing basic visual manipulation, it will also accurately preserve XAML format through switches between the XAML editor and the visual designer.

This is the first of a series of posts about the architecture of the Cider designer. Cider isn’t going to be shipping for a long time, so this isn’t information you can immediately put to use. Actually, I’m hoping that by publishing our plans very early like this I can get feedback about what you like and what you don’t like. That way I can get the stuff you don’t like out of the product before you see it. I’m going to roll this out by first describing to you how everything works, and then I’ll get into what the “everything” part is.

I've begun reading Charles Petzold's blog and his post of an old English poem mentioning Avalon made me think back to our choice of the code name "Cider" for the Avalon designer we are producing. Where did Cider come from? It is surprising how much time you can spend coming up with a code name...