Home arrow C# arrow Page 3 - Custom Controls and Design-Time Support: Part 2/2

Custom Controls and Design-Time Support: Part 2/2

Creating custom controls is a key technique in .NET development. This article by Matthew is the second of a two part series where he looks at how to create a custom Windows Form control that behaves properly in Visual Studio .NET.

Author Info:
By: Wrox Team
Rating: 4 stars4 stars4 stars4 stars4 stars / 25
January 13, 2003
  1. · Custom Controls and Design-Time Support: Part 2/2
  2. · The DirectoryTree
  3. · Filtering Control Class Members
  4. · Designer Verbs
  5. · UITypeEditors
  6. · Custom UITypeEditors
  7. · Conclusion

print this article

Custom Controls and Design-Time Support: Part 2/2 - Filtering Control Class Members
(Page 3 of 7 )

From time to time, you might want to hide a control event or property from the design-time view of the developer.

For example, every control provides a Text property, because every control inherits from the base System.Windows.Forms.Control class.

However, not all controls can effectively use the Text property. For example, the TreeView control doesn't actually use its Text property - you can set it in code, but it won't modify the user interface. For this reason, the Text property is not displayed in the Properties window.

If you are defining a property, you can use the Browsable attribute to keep it from appearing in the Properties window. However, consider the TreeView control, which provides a Nodes collection.

The DirectoryTree inherits the Nodes property, and allows it to be modified at design-time, even though the list of nodes is built automatically at runtime based on the Drive property.

This conflict means that there are really two ways the developer can alter the Nodes collection-indirectly through the Driver property, or directly through the Nodes collection, which is sure to lead to a great deal of confusion.

Unfortunately, because the TreeView.Nodes property is not overridable, you can't use the Browsable attribute. However, you can create a custom designer that ensures it won't appear at design-time.

To use filtering with the DirectoryTree, create a custom designer class that derives from ControlDesigner:

public class DirectoryTreeDesigner : ControlDesigner

protected override void PostFilterProperties(
System.Collections.IDictionary properties)


This designer overrides the PostFilterProperties() method, and removes the Nodes property from the properties collection.

The next step is to link the custom designer to the DirectoryTree control. To do this, use the Designer attribute, and specify the appropriate designer type.

public class DirectoryTree : TreeView

Note that the Nodes property is still accessible in code. This allows clients to perform other useful tasks (like enumerating through the collection of nodes) at their discretion. However, it can't be designed, and it won't be serialized.
blog comments powered by Disqus

- Introduction to Objects and Classes in C#, P...
- Visual C#.NET, Part 1: Introduction to Progr...
- C# - An Introduction
- Hotmail Exposed: Access Hotmail using C#
- Razor Sharp C#
- Introduction to Objects and Classes in C#
- Making Your Code CLS Compliant
- Programming with MySQL and .NET Technologies
- Socket Programming in C# - Part II
- Socket Programming in C# - Part I
- Creational Patterns in C#
- Type Conversions
- Creating Custom Delegates and Events in C#
- Inheritance and Polymorphism
- Understanding Properties in C#

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2018 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials