Are my assumptions about OnInit() correct?

  • Thread starter Thread starter beginwithl
  • Start date Start date
B

beginwithl

hi

I recently started learning Asp.net and there are quite a few things
confusing me

1) Calling OnInit() on a control starts initialization phase for that
control.


a) I assume OnInit phase of a child control must be completely
finished before parent’s OnInit phase can begin?


b) I also assume that all user-defined event handlers called by
child’s Init event must also be finished before parent’s OnInit() is
called?


c) I also assume OnLoad() can’t be called on any control until OnInit
() has been called on all controls on a page?




2) Say some property stores an instance C into a Viewstate. Now if we
mark C as dirty, then I assume Viewstate will serialize ( and thus
remember across postbacks ) all values that members of C hold?



3) OnLoad() fires Init event. Now why would you choose to do something
directly in OnLoad() and not in one of event handlers subscribed to
the OnInit event?



Thank you
 
yes and no.

1) yes
a) false
b) false
c) false


controls have a life cycle (simplified):

oninit
load view state
loadpostbackdata
onload
on postback data events (onchange,etc)
on postback events (click, etc)
prerender
save viewstate
render
dispose
unload

a controls oninit is not tied to its child controls. if you need to
access a child control, call ensurechildcontrols and put your child
contruction there. of course you can create you children as late as
prerender or even in the render event. in the case of a repeater, its
children are not created until a databind is done.

every control goes through its lifecycle, but as child controls can be
created at various times in its parents lifecycle, you can not assume
when a particular controls event s will occur.

2) viewstate is stored via serialization to a hidden field. no dirty bit
is required. the viewstate object must be seralizable.

3) false, onload does not fire oninit. oninit fires before veiwstate and
postback data is applied, so if the code needs to know the postback
value, then oninit is too early. onload fires after viewstate and
postback data has been applied.

-- bruce (sqlwork.com)
 
hi


yes and no.

1) yes
    a) false
    b) false
    c) false

controls have a life cycle (simplified):

  oninit
  load view state
  loadpostbackdata
  onload
  on postback data events (onchange,etc)
  on postback events (click, etc)
  prerender
  save viewstate
  render
  dispose
  unload

a controls oninit is not tied to its child controls. if you need to
access a child control, call ensurechildcontrols and put your child
contruction there. of course you can create you children as late as
prerender or even in the render event. in the case of a repeater, its
children are not created until a databind is done.

every control goes through its lifecycle, but as child controls can be
created at various times in its parents lifecycle, you can not assume
when a particular controls event s will occur.

I realize that is the case when it comes to dynamic controls. But I
was asking ( sorry about that … I should’ve pointed that out in my
post ) about declarative controls.
Anyways, as I understand the following quote, it implicitly states
that OnInit phase of a child control must be finished before the
OnInit phase of a parent control can even begin – I assume that since
it claims that before OnInit phase of a parent begins, TrackViewState
() is already called on a child control, and as far as I know,
TrackViewState() is called at the end of control’s OnInit phase, thus
even after Init’s event handlers are called. From that I assumed that
even Init’s event handlers must be finished before parent’s OnInit()
can begin?!

From http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx


“The trouble is ASP.NET does not provide an easy way to
programmatically initialize properties of child controls correctly.
You can override OnLoad and do it there -- but then you're persisting
data that probably doesn't need to be persisted into ViewState. You
can override OnInit and do it there instead, but that suffers from the
same problem. Remember when we learned how ASP.NET calls TrackViewState
() during the OnInit phase? It does this recursively on the entire
control tree, but it does it from the BOTTOM of the tree UP! In other
words, as a control or webform, the OnInit phase of your child
controls occurs BEFORE your own. A control will begin tracking
ViewState changes in this phase, which means by the time your own
OnInit phase begins, your child controls ViewState are all already
tracking!”


2) viewstate is stored via serialization to a hidden field. no dirty bit
is required. the viewstate object must be seralizable.

So viewstate does serialize the whole object ( including all members
and their values )?
3) false, onload does not fire oninit. oninit fires before veiwstate and
postback data is applied, so if the code needs to know the postback
value, then oninit is too early. onload fires after viewstate and
postback data has been applied.

That was a typo.What I meant to say was that OnLoad() fires Load event
and thus, why would you choose to do some operations directly in OnLoad
() and not in one of event handlers subscribed to Load event?
Similar question for why would you choose to do something in OnInit()
and not in one of event handlers subscribed to Init event?



thank you
 
Back
Top