Using the Extender Control
The extender control does absolutely nothing on its own to enforce security. It serves merely to add the property. We should make clear that security at the user interface level is less about enforcing security than it is about representing visually the underlying security of the business logic and data engine layers of the application. It may be deemed impetuous even to presume that user interface security alone will stand as an impediment to a determined belligerent. We therefore represent the underlying application security in the UI by writing code that will examine the user's security principal and the control's extended property and take action to hide or disable those controls with which the user is not authorized to interact. This code will need to be invoked for every form that gets loaded. This would require a single line of code to be added to the Form's Load event:
Alternatively, an abstract base form can be created which can run this code automatically. Your forms would then inherit from this abstract base form.
The code mentioned would need to loop through each control within the form. A normal looping structure is insufficient to accomplish this though, since looping through the Form.Controls collection will only provide controls whose parent is the form itself. In other words, it will not pick up any controls whose parent is another container.
For example, if the form contains a panel or a frame then any controls that are placed on the panel or frame would not be accessible by simply looping through the Form.Control collection. The application of a Depth First Traversal recursive loop, however, ensures that all form controls are appropriately secured, as you can see in Listing 1 (this code is part of a code block "helper" class and thus uses additional parameters that are not exposed to the user of the extender control). Take a minute to make sure you understand why the code in Listing 1 is needed. Remember that if every control were accessible directly from the Form's Controls collection then recursion would be superfluous. Every control is not accessible from this collection. Now take a bite of that sandwich and swallow.
At this point everything will work, but there's one situation you might be concerned with. Does your system need to be smart enough to prevent a software developer from writing code that makes a hidden control visible? Should the security system be smart enough to prevent such an occurrence? The answer to this question is completely up to you. If the control must never be visible/enabled then you can prevent it by overriding the Visible/EnabledChanged events of the controls on the form. Do this wisely and avoid the need to manually write code to listen to each event. Do some creative delegate remapping, partition the code into code blocks, use form inheritance, and you can accomplish what you need to without giving yourself carpal tunnel syndrome.
The Value Add
While the underlying intricacies of UI security are certainly interesting, a primary goal is to enable even the most novice developer to take advantage of UI security in their applications. Bring the advantage of user interface security into your applications with as little as a single line of code. Code less; have fun.