Implementation Details: The Extended System Control
An extended system control derives from a single, existing standard .NET control (e.g., GroupBox), as distinct from the extended user control, a control derived from one of your own controls (such as the ClockControl discussed in the earlier article). See Table 3.
Table 3. Extended System Control Usage
|Extended System Control
|Add User Control Dialog
||Start as if you are making a composite control; use the User Control template.
||In the editor change the base class to the system control that you wish to inherit from.
Compile and you will get one or two errors in the accompanying designer-generated code (xxx.Designer.cs). Just comment out the offending assignments to AutoScaleDimensions and AutoScaleMode.
||When you change the base class, the designer automatically updates the canvas from a blank drawing canvas to a canvas without a drawing surface. You are limited to setting properties for components you add.
|Runnable in test container?
Unlike the previous controls you have seen, the designer canvas presents a different rendering for this control as the table shows. For the previous controls, and indeed for standard Windows Forms, the designer has two parts: the top part is the canvas where you may drag visual controls; the bottom—the component tray—is where your non-visual components reside. That is, in the .NET framework, a control has a visual rendering while a component does not. This difference dictates the behavior when you drag one onto the designer surface from the toolbox. When you drag a control, Visual Studio renders a visual representation (e.g., a button, label, grid, etc.) on the canvas. When you drag a component, nothing shows up on the graphic canvas; instead, Visual Studio places the component in the component tray at the bottom. Whether on the canvas or in the component tray, you can still select the element and view/edit its properties in the Properties window.
|Figure 2. A Component Without a Drawing Canvas: Extended system controls don't use the design surface; Visual Studio places them all in the component tray. You may drag controls and components here to give you access to their properties but the controls will not be rendered visually.|
However, Visual Studio is unable to render the base class for an extended system control (it's unclear why) so it does not even attempt to show the canvas: the component tray occupies the entire designer window. That's why you get the message in the Designer Canvas row of Table 3. You may still drag controls and components onto the designer surface, but they all go into the component tray as in the example in Figure 2
As an aside, note that this capability supports an interactive, visually-oriented programming methodology even for non-visual components. The designer in Visual Studio lets you add components to the component tray and then set their properties in the Properties window, leveraging appropriate property editors as needed. That is, if your component has a property that is a Color, the Properties window will automatically open a color picker when you click on the value field of that property. That is a lot more intuitive than trying to decide in code whether you want Color.CornHusk
If you really want to have a visual rendering of your extended system control, then you need to make it a composite control instead of an extended system control, where your composition includes only one constituent control. Think back to the ProgressBarMessager control discussed in the earlier article
. As discussed, the ProgressBarMessager is a composition of several elements—a ProgressBar, a Button, and several Labels. But if you simply wanted to create some type of enhanced ProgressBar, you could discard all the other controls, leaving only the ProgressBar, and it would then be viewable in the designer.