Darren has posted up his round one solution. I’ve had a chance to give it a quick once over and I can see where he is coming from with the design. It is similar in spirit to the extender provider approach although he puts the custom security code in the controls themselves.
I think Darren’s approach will fall down where Josephs will which is the cost of continually sub-classing controls. For example, I could add close to any of the other controls on the toolbox right now and they would just work immediately – no need to do any work to get any benefits.
Admittedly that might be a bit short sighted considering somethings can be harder to do from an extender provider, but it’d be interesting to see if I would ever have to pay for the decision to use an extender provider over sub-classing. Actually, we used this extender provider approach on a project after most of the UI had been constructuted and it saved us a great deal of time.
One hybrid approach you could take is sub-class the container controls like forms and user controls. Any component on the design surface can be an extender provider, so you can get some of the benefits without actually having to drag the thing on in the first place.
If you look at the design surface in VS.NET today you can see a number of properties that don’t actually exist – such as Accessibility, this is an example of an extender provider which is baked into the design surface without you having to do anything.
Finally – Darren makes a really good point about the potentially ever growing if-block. I had contemplated factoring this out into some kind of factory of control handlers where the factory dynamically discovered a handler for each control – but the only non-hardcoded way I could think to do it was by a brute force search of the assemblies loaded into the AppDomain – since I only had one specialisation so far I didn’t think it was worth it.