Help - Server Control Hierarchy Built Twice

[dasein fiasco]

I'm sure this is a design question that is commonly encountered, but I
can't find any resources which explain how to solve it. I would deeply
appreciate any advice.

Basically, when building a composite server control, I'm trying to
avoid having to build the control twice. Here's why this happens:

The routine for building the control can be called from two places:
(1) CreateChildControls, or (2) DataBind. If DataBind is called, it
sets ChildControlsCreated to false, and creates the controls itself.
If it isn't called, then CreateChildControls is automatically
invoked, and creates the controls from the ViewState. Great! This
works fine.

However, several of the child controls can change the state of the
control – essentially, the control has a table, and the table can be
rendered in different ways, so you can select different rendering
options from the control (horizontal, vertical, etc.) via
dropdownlist controls.

When one of these controls is selected, it registers an event, and
calls a routine to change some properties of the control that tell it
to render differently. However, postback events like this occur after
DataBind, and more importantly, after CreateChildControls.

If one of these events is raised, when CreateChildControls is invoked,
it doesn't know that the properties of the control are about to
change, and therefore the rendering it will perform is about to be
obsolete. What happens is that it builds the control hierarchy, then
later the event is called, which changes how the control hierarchy
should look, and so it MUST REBUILD the control hierarchy again to
respond to the changes posted by the event. Therefore, I'm building
the control hierarchy twice.

I assume I'm doing something drastically wrong in my design here, but
I can't figure out how I should handle this differently. Please, any
advice, links, pseudocode, admonishments would be greatly
appreciated.

Thanks in advance.

 

[Wilco Bauwer]

If I understand you correctly, a (some?) child controls can change
properties of the control itself, which effectively affects the child
controls themselves.

In case I am correct, then the answer will be no. Well, lets say
there's just not a proper way to do it. * The reason for this is
relatively easy, once you understand what is going on. Basically, after
a postback, an event is raised which you have to handle to do your
stuff. However, that event wont be raised if the control does not get a
chance to do so. It will (normally) only be given a chance to raise an
event by the page (based on postback data, etc.). But if the control
does not exist, or is just not participating in the control hierarchy,
the page will not be able to find that control. And the event would not
be raised.

Long story short: the control has to be there after a postback, because
otherwise you will not be able to handle the event. However, you want
to re-create the child controls once you handle that event, which means
you are creating the child controls twice (however they are not the
same as the previous set of child controls, right?). You can't do
anything about that.

* It can be done if you would check the postback data at a very low
level, which gets quite ugly and is probably not worth the hassle.

(As a sidenote: this also happens in case of for example a datagrid. If
you go into edit mode, you set the EditItemIndex (in edit's
eventhandler) and you end up re-binding the data. Re-binding the data
means the grid will re-create its controls.)

HTH.