Select your preferred language

Design time property usage. 

As you may have gathered by now, I am a great proponent of the component based .net architecture.  I'm particularly pleased with the reusability aspects of components and controls and spend a lot more time creating control DLL's than applications these days because often, creating an application has become a simple matter of dragging a few of my extensive library of custom controls on to a form. A question which has cropped up on numerous occasions recently has been "I've created a control to which I've added my own properties, when I drag this control onto a form I see all those properties but I also see all the old ones inherited from the base class.  How can I get rid of those base class properties? "

This site carries an article about filtering properties for the property grid but this article was specifically aimed at runtime editing applications where you might use of property grid as an editing tool in your own applications.  in this instance however, you need to be able to filter a component properties at design time. Thankfully, the design team at Microsoft also had the same problem and have built something into the design time architecture which enables you to simply and efficiently remove any properties that you don't require. Furthermore, you can add or remove events.

Pre and post filtering of properties, events and attributes. 

Although most components are capable of being used in the IDE without a specialized designer, it's often a good idea to create a designer because it provides so many more options.  Associating a designer with a component or control is simple because there is an attribute provided for the purpose.  The designer for a control should be based upon ControlDesigner which provides six methods for adding or removing properties, events and attributes to or from a Control at design time.

This listing shows how a control that has the background color set permanently to PowderBlue uses a designer to remove the BackColor property so that it can no longer be changed at design time. Note how the designer's associated with the Control using the Designer attribute.

Filtering many properties.

Filtering properties one at a time may laborious and so a simple method is to provide an array of strings, one for each property to be removed and go through them with a loop as shown in this listing.

Pre or post?

The pre filter methods are there to enable you to add or remove properties, events or attributes and the post-filter methods allow you to modify them.  Why should you wish to modify properties or events in a control? The answer is that in certain circumstances properties used at design time should not affect the actual control which is running in the design window.  For example, it would be pretty useless if you were to be designing a Control and set its visible property to false only to have it disappear from the design surface.  Why would you want to add properties to a control? The answer here is that at design time you may wish to have some property that doesn't appear at runtime. Examples of design time only properties are the Locked or Modifier properties.

Shadowing properties.

Shadow properties provided by the designer enable the user to manipulate values at runtime and have those values serialized in code such as the InitializeComponent method without actually passing the values to the control at design time.  Consider a scanario where an object was only usable for a certain time, perhaps as a security feature, and which had a timeout value and some method of enabling the timeout. It would be annoying if, once set, the object became unusable in the designer after 30 seconds or whatever the value was, so there needs to be a way of setting the values without actually setting off the timeout. The following few listings demonstrate this. Here is the control with the timeout system in place.

The designers initialize method enables you to get copies of properties in the component itself so that the designers view reflects that of the component. One or more of the properties returned by the control can be replaced by properties owned by the designer so that the user thinks they are setting the properties of the control but without changing the control. This is how the designer manages the properties. This is how the properties in the control are replaced by those in the designer. This is the complete listing of the designer.

Summary

In this article you've seen how to remove unwanted properties from the design time representation of your derived controls and seen how properties may be replaced or modified so that potentially troublesome runtime behaviour doesn't affect the design time experience.

You can find the Source Code files here.

Return to the main index.