Question

Must every control in the Visual Studio WinForms toolbox descend from Control?

Does Visual Studio support window-less controls?

---

Every control you add to the Toolbox in Visual Studio:

must¹ descend from Control, which is a wrapper around a windowed control.

Unfortunately, Windowed controls are very “heavy”; having a lot of them, especially nested, causes performance in WinForms to suffer.

In the past i’ve dealt with the problem by creating aggregate custom controls. The custom control internally contains other window-less controls:

• an image (windowless version of a PictureBox)
• title label (windowless version of a Label)
• subtitle label (windowless version of a Label)
• border (windowless version of a Panel)

These are useful to mitigate performance problems in WinForms, but they’re stuck inside code.

i would like to do what other development environments allow, is a version of Control that doesn’t create a Windows window. i would like the ability for the Visual Studio toolbox to accept **window-less* controls.

i know that if i really wanted window-less controls: i should switch to WPF. But that’s overkill.

Does Visual Studio WinForms support window-less controls?

¹ or not

Answer 1

Yes and No.

First, check out this article from the venerable Raymond Chen: http://blogs.msdn.com/b/oldnewthing/archive/2005/02/11/371042.aspx

Yes. You are welcome to create “controls” that do not derive from Control. I have created several windowless controls in my application that natively support clicking, layering, etc., I draw them to an offscreen buffer, and then paint them directly on some parent Form or Control (such as a PictureBox). This is straightforward to do but not simple, as you will need to manage everything yourself in code.

No. Any windowless controls will not be supported in the Windows Forms designer for any of the Control-derived controls designers (such as placing them on a Panel or Form) so you won’t have drag-and-drop form design.

As Hans has pointed out, the ToolStrip and MenuStrip (a windowless control) are such examples. Notice that when you create a new MenuStrip on a Form, the MenuStrip is placed in the Component tray underneath the form. The MenuStrip has a custom set of Designer classes associated with it to support the custom painting and “Type Here” functionality, as well as the dialog boxes to add and remove menu items. Note that the “child” windowless controls, such as the ToolStripButton, are not available in the ToolBox for drag-and-drop support directly onto the form – only the custom designer knows about it. The custom designer for the MenuStrip also supports selecting the child windowless controls so that you can edit the properties of each item in the Properties window.

I can’t imagine this is suitable for your situation (unless you are creating some controls for resale), but if you are very determined, you can create designer support in much the same way for your set of windowless controls:

1. Create a class that derives from Component that will be used to manage your Windowless controls. For example, you could call this class WindowlessWidgetManager. After you compile, this control will be in your toolbox. The WindowlessWidgetManager can contain a collection of your windowless controls, and provide painting and other UI support for a canvas such as a Form or PictureBox.
2. Create a designer class that derives from ComponentDesigner that supports things such adding and removing your custom controls at design time. For more information, see http://msdn.microsoft.com/en-us/library/system.componentmodel.design.componentdesigner(v=VS.90).aspx

This is a very lengthy process with a number of caveats, but if that is what you wish to achieve, the functionality is there.