question about LifeCycle for controls that change the 'shape' of their control tree?

question about LifeCycle for controls that change the 'shape' of their control tree?

Post by Robert Kor » Fri, 02 Jul 2004 17:23:47


our thinking is great but remember there is another property called
ChildControlsCreated, which you should set to true in your
CreateChildControls at the end. So consecutive calls to EnsureChildControls
won't actually rebuild the control tree.

EnsureChildControls is a method that just checks that control tree is
created. And it checks the above boolean property. So whenever you do
something on the control (set/get some property that should access any
control within the tree), you should call EnsureChildControls() method.

Actually when page is rendering it also calls EnsureChildControls
recursively on it's controls. So all controls are valid before rendering and
before the response is sent to the client all controls have a true value in
childcontrolscreated property.

--
RobertK
{ Clever? No just smart. }

"Sky" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
clarification
which
page
once
re-EnsureChildControls().}}
start
finish
almost
should
jump,
possible,
time
being


 
 
 

question about LifeCycle for controls that change the 'shape' of their control tree?

Post by Sky » Sat, 03 Jul 2004 13:35:43

obert -- thanks for your response ;-)
Yes -- I did know about the EnsureChildControls() combo with the
ChildControls Created bool...
Which by the way seems to do more than just cover up a private bool -- I
noticed that if I CreateChildControls, and not set
ChildControlsCreatedExplicitly, and not call base.CreateChildControls(), the
ChildControlsCreated is set automatically (!!!). How, where, I don't know...
Maybe the code behind ChildControlsCreated looks something like

get { return (_ChildControlsCreated)||(this.Controls.Count>0);}

That aside, it still means that everytime EnsureChildControls is used in a
property get/set, one is adding a lot of jumping around and checking, for
something, that in my mind, should already have been taken care of... What i
mean is that the code that is happening is something like:

string MyProp(){
get {
EnsureChildControls();
//which does
* jump to addr of EnsureChildControls()
* if ((ChildControlsCreated)||this.Controls.Count>0)){return
true;}else{CreateChildControls();}
//back to your code:
//etc.
}
}
In other words -- its still atleast one addr jump, with all that the
Stack/Reflection stuff of C# does... -- a conditional, a possible iterator
creation, a count, then return...

Now, I know that I am really being a pain in the bum asking about a realy
small little waste of bytes -- but I am asking for the sake of getting a
good grip on the life-cycle -- because as far as I can tell , 3 books = 3
different understandings !.... It seems that there is a lot of confusion
out there about how to make a webcontrol be as flexible as a form control...
Or..which is what I suspect -- it's not the books, it's me who is
confused -- hence the questions ;-)


PS: What were your thoughts as to what I am doing about breaking up the
rendering into two parts (CreateChildControls/PreRender)? I'm working out
here alone at home and have little contact with other asp.net programmers,
so most of my methodology is home - brew...And sometimes, it gets so hard to
do something, that I start wondering if I am totally looking at the whole
thing from the wrong angle ....

Very best,
Sky





"Robert Koritnik" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
EnsureChildControls
and
in
server
there
right):
the
the
I
if
Examples/books/articles
reason



 
 
 

question about LifeCycle for controls that change the 'shape' of their control tree?

Post by Robert Kor » Sat, 03 Jul 2004 16:56:15

bout two step WebControl creation is a smart thing. Actually I had the same
thing in mind once. First you have to create those controls that will be in
question when ProcessViewState phase begins. That's what you wanted to do.
The second part in PreRender should position those already created controls
into new containers. Seem reasonable. I once tried to do the same thing, but
eventualy gave up, because I work in a multi developer environment and it
would probably confuse others that would be (maybe) reediting my custom
control.

there's also a great article on ViewState, which also covers some of the
very interesting part of the control's lifecycle:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconcontrolexecutionlifecycle.asp

The other thing about ChildControlsCreated is somewhere else I think. I also
saw, that EnsureChildControls gets executed even if you don't Create them
and set childcontrolscreated to true. To me it looked more like (not like
your get { checking two conditions}) checking the private bool and if false
calling ensureChildControls and thus making it true. Because I did something
like that. I created CreateChildControls, but I didn't call it in any method
or property set/get. But in the end my webcontrol got created WITH
CreateChildControls method. Looks like that a Page object before responding
back (probably just before SaveViewState) calls EnsureChildControls
recursively over all its containing controls.

--
RobertK
{ Clever? No just smart. }


"Sky" < XXXX@XXXXX.COM > wrote in message
news:uaMdU3# XXXX@XXXXX.COM ...
the
know...
i
((ChildControlsCreated)||this.Controls.Count>0)){return
control...
to
the
properties
required...plus,
once
overkill????
Constructor: