Click here to Skip to main content
13,049,814 members (94,114 online)
Click here to Skip to main content
Add your own
alternative version


3 bookmarked
Posted 14 Jul 2011

DesignTime adding of Controls to a UserForm on a WinForm

, 15 Jul 2011
Rate this:
Please Sign up or sign in to vote.
An interesting change in behavior in VS 2010 Pro ?
Note 1: The result reported here is a hypothesis based on testing in Visual Studio Pro 2010, with the WinForms project set to compile against .NET FrameWork 4 Client Profile, only.

Note 2: This tip does not consider using Component Classes which are sub-classed as Containers. Only UserControl is discussed here.

Note 3: I appreciate all feedback, and correction, on the content of this Tip: hypothesis refutation welcome.


0. Consider the action of drag-dropping a Control from the ToolBox onto a Panel, or GroupBox, on a Form at DesignTime: you will get visual feedback from the drop target, and the dropped Control will become a child of the Panel or GroupBox.

However, if you create a UserForm in a WinForms .NET solution, and then build the project, and then drag-drop an instance of the UserControl on a Form from the ToolBox: it will not 'accept' ('swallow' may be a better term)other Controls: in other words, the drag-dropped Controls will not become 'child' controls of the UserControl: rather, they will become 'child' Controls of the Form. And you do not have any visual feedback as you do when you drag-drop to a Panel, or other Container Control.

  1. An early Microsoft tech-note(1)[^] showed how to make a UserControl at DesignTime in a Windows Form 'accept' Controls drag-dropped from the ToolBox. This was accomplished by using the IDesigner attribute.
  2. In 2009, Henry Minute published a CodeProject article(2)[^] addressing the problem that a UserControl placed on a Windows Form at DesignTime inside another UserForm (i.e., nested) could not have new controls drag-dropped to it from the Visual Studio Toolbox, and have the UserControl 'accept' these dragged Controls as 'child' controls of the UserForm: these dragged Controls would remain 'child' controls of the Parent Form.

Something appears to have changed in VS 2010

0. adorning a UserControl with the IDesigner Attribute like this:
// you must have a reference set to System.ComponentModel.Design;
using System.ComponentModel.Design
namespace yourForm_NameSpace
[Designer("System.Windows.Forms.Design.ParentControlDesigner, System.Design", typeof(IDesigner))]
    public partial class yourUserControl: UserControl
      // your UserControl code

  1. As expected (based on the Microsoft tech-note cited: (1)): you now will find that you can drag-drop other Controls onto the top-level UserForm at DesignTime, and get DesignTime feedback.

  2. What is not expected: you can nest instances of this UserControl inside other instances of this UserControl, and you will still be able to drag-drop new Controls from the ToolBox onto the nested UserControls, and get Design-Time feedback, as if you were drag-dropping.

  3. What is also not expected: you can drag-drop a Control onto the Form surface, and then move it inside a top-level or nested UserControl adorned with the IDesigner Attribute, and it will be automatically 're-Parented:' however, you will not get the Design-Time drag-feedback you do when you drag-drop from the 'ToolBox.


VS 2010 Pro, Windows Forms, now makes it easier to deal with DesignTime support ... via drag-drop of Controls from the ToolBox ... of nested UserControls without going to the lengths that Henry Minute went to in 2009 ... of implementing some complex DesignerProvider code ... in his excellent CodeProject article cited here(2).


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Chief Technology Officer
Thailand Thailand
Human being, mortal, flawed.

You may also be interested in...


Comments and Discussions

GeneralRe: Thanks, Henry, I'll download your code, and examine it tonig... Pin
BillWoodruff17-Jul-11 17:09
memberBillWoodruff17-Jul-11 17:09 
GeneralRe: Bill, I have created a small app (using VS2008) to demonstr... Pin
Henry Minute17-Jul-11 9:30
memberHenry Minute17-Jul-11 9:30 
GeneralRe: Thanks, Henry. I would appreciate your commenting on my obse... Pin
BillWoodruff17-Jul-11 4:23
memberBillWoodruff17-Jul-11 4:23 
GeneralHi, Johann, Your question is a very good one, and one I also... Pin
BillWoodruff15-Jul-11 14:05
memberBillWoodruff15-Jul-11 14:05 
Hi, Johann, Your question is a very good one, and one I also ask: "Why did we go to so much trouble, a few years ago, to make UserControls support ContainerControl design-time behavior, and even more trouble ... see Henry Minute's excellent code ... to make them support ControlContainer design-time behavior when nested in UserControl instances of their own type ?"

After all: ContainerControl has 'been there' from .NET FrameWork => .NET 1.0, and now ... I'm not sure about about .NET FrameWork < 4 ... even ContainerControl's direct ancestor, System.Windows.Forms.ScrollableControl, supports drag-dropping onto top-level, and hosting controls of its own type (nesting). In my experiments: ScrollableControl is as 'high-up' the ancestor tree of 'Control' as I've successfully tested for the presence of this DesignTime behavior in .NET 4.0.

And, while UserControl, Form, and ToolStripPanel, etc., all directly inherit from the ScrollableContol object, it's interesting to note the absence of this DesignTime behavior with UserControl without the IDesigner Attribute adornment.

Certainly there are some key run-time behavior differences in these different 'children' of ScrollableControl: a UserControl will automatically pass the Focus to its child components, and will not respond to Keyboard intercept handlers ... even though VS Studio certainly lets you code them. The Control on a UserControl with the lowest TabIndex fires the 'GotFocus event on launching the app, and on switching between Forms.

A Form actually can be put inside another Form as a child Control, by setting its TopLevel Property to 'false, and adding it to the host-Form's Controls collection in your code (note I am not referring to MDI architecture, or the 'Owner/Owned' relationship here) ... of course you don't see a WinForm object on your ToolBox in VS Studio.

The question: why use a UserControl, rather than a ContainerControl, just to get DesignTime support for drag-drop of Controls, and nesting ? ... What do you not get by using a ControlContainer ? Is one I hope to answer in a future tip.

I debated whether this observation ... limited to .NET 4, and UserControl ... was 'worth' a Tip, and decided to put it out there; perhaps it should have been in the form of a question ? I'm hoping Henry Minute will read this and comment.

Thanks for your feedback !

best, Bill
GeneralHmm, I'm not really into this subject, but when I once creat... Pin
johannesnestler14-Jul-11 22:59
memberjohannesnestler14-Jul-11 22:59 
GeneralRe: Hi Johannes, I've posted a message to Henry Minute, in the f... Pin
BillWoodruff16-Jul-11 14:36
memberBillWoodruff16-Jul-11 14:36 
GeneralRe: You are quite correct. You can base your own controls on Con... Pin
Henry Minute17-Jul-11 1:09
memberHenry Minute17-Jul-11 1:09 

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
Web01 | 2.8.170713.1 | Last Updated 15 Jul 2011
Article Copyright 2011 by BillWoodruff
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid