Mark Olbert
2/16/2007 3:28:00 PM
I'm building a custom control which is essentially a customized version of the Wizard control, although it doesn't derive from the
Wizard class. It's designed so that you can add a sequence of a limited number of types of steps to the control (e.g., an
Introduction step, a grid-select step). These are currently persisted as child controls of the custom control.
I'm curious as to "best practices" regarding several issues:
1) It occurred to me I could, instead of persisting child controls, persist the information needed to create child controls as
complex properties of the custom control. I would then use that information to create the child controls when needed. Right now the
child controls are added by AddParsedSubObject() to a private list, and then added to Controls during CreateChildControls(). That
seems like it would be more memory intensive than simply storing the information and creating the child controls on demand.
On the other hand, when I tried to persist a complex property I ended up having to prefix it with the tag prefix in the page markup
(e.g., "<cc1:ComplexProperty>"). I find this ugly. But while using a custom builder lets me avoid it for child controls, there
doesn't seem to be a way to attach a "custom property builder" to the defining class for a complex property.
2) I'd like to expose the list of child controls at design-time in the property panel the way the Wizard exposes WizardSteps. But if
I do that, how do I get changes propagated back to the page markup (the child controls are persisted within the markup for the
control)? I don't see how that would happen if I just expose the (currently hidden) list of child controls as a public property.
Does doing this involve creating a design-time only property in the control designer, and then working some magic to propagate
controls back to markup?
- Mark