Hosting a Designer Surface in Windows Forms Part 1

{if you are just tuning in, you may want to review:

Designer[0]

}

The most important things we’ll be working with is our class that implements System.ComponentModel.Design.IDesignerHost.  This class is the hub of many designer activities such as creating the designed components, Siting Components, and managing designer transactions.  In my case I went a slightly different route for transactions but this class is still very important.  Review the description (http://msdn2.microsoft.com/en-us/library/system.componentmodel.design.idesignerhost(vs.80).aspx) and a trivial sample implementation on MSDN.

Let’s take a look at a few lines of code after where we left off last, after LoadToolBoxItems() from the last article:

            //Setup the control that will hold all the template junk:

            _form = (BlankDesignForm)_designerHost.CreateComponent(typeof(BlankDesignForm));

            _form.Size = new Size(612, 792);

            _form.TopLevel = false;

            _form.Text = "Print Template";

            _form.FormBorderStyle = FormBorderStyle.None;

            _form.Font = new Font("Tahoma", 9);

            _baseFont = _form.Font;

            _form.Location = new Point(5, 5);

            _rootDesigner = (IRootDesigner)_designerHost.GetDesigner(_form);

            _designerView = (Control)_rootDesigner.GetView(ViewTechnology.Default);

            _designerView.Dock = DockStyle.Fill;

            _viewHostPnl.Controls.Add(_designerView);

Usually the under the cover plumbing interacts with the designer telling it what was selected in the IToolBoxService implementation and therefore what Type of Component to create.  We manually create a BlankDesignForm because it is the canvas that will contain the visual representation of all other designed Components.  Note that we can guarantee that the type of IDesigner created in this case is an implementation of IRootDesigner as opposed to IDesigner.  The first designed component is the Design Time Root.  An IRootDesigner, as opposed to other classes buried in the framework like System.Windows.Forms.Design.LabelDesigner gives us what we need to display the entire Designer Surface in our program, through its GetView() method.

The BlankDesignForm exists in order to gain some things specific to our problem domain such as drawing the dotted line around the page’s print margin you saw in the last article, but also to lose some functionality inherent to Windows Forms.  I’m talking about scaling.  While not explicitly related to the Designer Surface discussion I did run into this again during these articles and it’s a nice thing to know about anyway.

In order to be more Accessible, Windows Forms will try to scale the overall size of forms and their children in one of two ways in .Net 2.  The first is DPI scaling, meaning if the screen resolution changes from the design time resolution.  The second and more curious is font scaling.  If you have a Form that is 800x600 at design time with 8.25pt Microsoft Sans Serif, and at run-time you set its Font to be 9pt Tahoma, the form and all children will resize by roughly the difference between 8.25 and 9pt.  I say roughly because the behavior does not appear to be perfectly mathematically dependable in a transitive fashion.  If I go from 8.25 à 9 à 63 à 12 à 8.25 I will not end up with a form that’s quite right with respect to its original self.  The child controls may not be positioned in exactly their original places or the size may not be quite right.  I found workarounds for some situations but ultimately the resizing of ScrollableControl and its various viewports and bounds defeated me, it’s a long story for another article.  It’s too bad this doesn’t work, since if it did this would be a swell way to implement Zoom-In and Zoom-Out in pre-WPF applications.  This is all a very long winded way of saying that I needed my program to be somewhat skinable with colors, font family, font size, set at run time by processing a skin file.  Since the WYSIWYG-ness of my final printed document is dependent upon the convention that a 612pixel by 792pixel form represents the same space and proportions as an 8.5” by 11” document printed at 72dpi using my Compact Framework printer driver (http://www.fieldsoftware.com) a little Font scaling error is too much Font scaling error but the GUI skinning could not be given up.  The BlankDesignForm’s main contribution to my mental stability, then, is:

        protected override void ScaleControl(SizeF factor, BoundsSpecified specified)

        {

            //Don't scale!

        }

So the designed area where every pixel counts will not participate in the magical Scaling-based-on-font woo that takes place from within the bowels of Component.OnFontChanged.

In the code figure above everything is obvious except for our IDesignerHost.CreateComponent(Type)  implementation from the DefaultDesignerHost class. 

        /// <summary>

        /// Instructs the DefaultDesignerHost to instantiate a new instance of componentClass, which

        /// is also assumed to be added to the list of components that this DefaultDesignerHost is

        /// designing for through an IContainer implementation.  The component is Sited after listeners are given a chance to cancel this operation via

        /// the ComponentAdding method of the contextual IComponentChangeSerice instance.

        /// </summary>

        /// <param name="componentClass">valid Type</param>

        /// <param name="name">Component Name/Site Name</param>

        /// <returns></returns>

        public IComponent CreateComponent(Type componentClass, string name)

        {

            IComponent newComponent = (IComponent)Activator.CreateInstance(componentClass);

            IComponentChangeService changeSvc = (IComponentChangeService)_parent.GetService(typeof(IComponentChangeService));

            changeSvc.ComponentAdding(new ComponentEventArgs(newComponent));

            ISite site = new DefaultDesignSite(newComponent, this, name);

            newComponent.Site = site;

Any and all design time classes will attach to the events exposed by an IComponentChangeService implementation if they care about what goes on with Components at design-time. The first issue is the code in red.  It doesn’t work.  Take a look at the IComponentChangeService interface events:

	Name	Description
	ComponentAdded	Occurs when a component has been added.
	ComponentAdding	Occurs when a component is in the process of being added.
	ComponentChanged	Occurs when a component has been changed.
	ComponentChanging	Occurs when a component is in the process of being changed.
	ComponentRemoved	Occurs when a component has been removed.
	ComponentRemoving	Occurs when a component is in the process of being removed.
	ComponentRename	Occurs when a component is renamed.

… and the public methods …

	Name	Description
	OnComponentChanged	Announces to the component change service that a particular component has changed.
	OnComponentChanging	Announces to the component change service that a particular component is changing.

Cruising MSDN shows that there is no public interface that forces any class to implement an OnComponentAdding or OnComponentAdded method.  While I don’t mind being left with a few design problems of my own to solve, this seems a little unfortunate since I am now forced to go outside the Design Time framework that’s been provided and implement something specific to my own Design Time environment.  It seems that it would be ideal to be able to give someone my ISelectionService or IComponentChangeService implementations without depending on behaviors that are outside the published contracts.  Of course I could just be missing something too :D.  Semantics being very important I chose the saucy name ITemplateDesignerComponentChangeService to represent my interface with the necessary methods added.  At least I didn’t just tack a “2” on the end of the original interface, yeah; I’m talking to you Sun.  Talk about lazy; nothing is worse than trying to determine if I should use SomeType or SomeType2.  Apparently this was considered a completely super practice in Java, but thankfully I don’t write Java anymore.

    interface ITemplateDesignerComponentChangeService : IComponentChangeService

    {

        void OnComponentAdding(ComponentEventArgs e);

        void OnComponentAdded(ComponentEventArgs e);

        void OnComponentRemoving(ComponentEventArgs e);

        void OnComponentRemoved(ComponentEventArgs e);

    }

I add an instance of a class implementing this new interface to my SerivceContainer.  Now if there are any classes buried in the framework that are not my own they will have access to an IComponentChangeService implementation for the purpose of event subscription, and my own code can ask for a Service Type implementing ITemplateDesignerComponentChangeService in order to access the extra methods.  The first few lines of our CreateComponent method now look like:

            IComponent newComponent = (IComponent)Activator.CreateInstance(componentClass);

            ITemplateDesignerComponentChangeService changeSvc = (ITemplateDesignerComponentChangeService)_parent.GetService(typeof(IComponentChangeService));

            changeSvc.OnComponentAdding(new ComponentEventArgs(newComponent));

            ISite site = new DefaultDesignSite(newComponent, this, name);

            newComponent.Site = site;

In the next article, we’ll start looking at more Service class implementations, where we tell the design-time framework about our Service implanting types, and the interactions between all of these pieces of the Designer Surface puzzle.