composite controls... Microsoft Press: Dev ASP.NET Server Controls

Discussion in 'ASP .Net' started by dx, Apr 8, 2004.

  1. dx

    dx Guest

    I have the Microsoft Press: Developing Microsoft ASP.NET Server Controls and
    Components book. It's starting to shine some light on control development
    but there is something about composite controls that I don't understand...
    I've included a snippet from Chapter 12 below on Composite Controls:

    <start>

    Override the CreateChildControls method to instantiate child controls,
    initialize them, and add them to the control tree. Do not perform this logic
    in the constructor or in the OnInit method.

    Let's examine the reason for this implementation detail. You must create
    your child controls in the CreateChildControls method--instead of creating
    them in a specific phase such as Instantiate or Initialize--so that children
    can be created on demand when needed in your control's life cycle. This is
    especially important when you create composite controls whose child controls
    handle postback data.

    <end>

    I do not understand this at all. It seems to me that the Init method would
    be a safe place to initialize the child objects since that method occurs
    before loading postback data or raising postback events (in the control life
    cycle.) What am I missing here?

    Much Thanks in advance.

    Stan
    dx, Apr 8, 2004
    #1
    1. Advertising

  2. dx

    Pete Beech Guest

    I've often wondered the same - and there are some people who don't bother
    with CreateChildControls at all - see
    http://www.wilsondotnet.com/Tips/ViewPosts.aspx?Thread=278 .

    Possibly its only useful in the case that the child controls change as a
    result of the postback (e.g. the expanding of a node in a simple serverside
    treeview control) - then, you can just set ChildControlsCreated = false to
    get them recreated (the next time EnsureChildControls is called.).

    I can't quite see at first glance why "this is especially important when you
    create composite controls whose child controls handle postback data.".
    Presumably, to get viewstate loaded, and postback data also, you would need
    to make sure EnsureChildControls was called in OnInit anyway - so why can't
    you just create them in OnInit.

    Maybe its more of a mini design pattern type thing - i.e., perhaps the
    ASP.NET designers considered a control whose child controls remain static
    (i.e. the actual objects in the Controls collection don't need to change
    based on some postback event or value) as a special case, and the more
    general case is that the Controls collection could vary on each postback. So
    they might have thought this is best handled by a separate function
    CreateChildControls, rather than coding directly in OnInit, and so tried to
    enforce this as a best practice.

    Its a very interesting question!
    Cheers,
    Pete Beech


    "dx" <> wrote in message
    news:...
    > I have the Microsoft Press: Developing Microsoft ASP.NET Server Controls

    and
    > Components book. It's starting to shine some light on control development
    > but there is something about composite controls that I don't understand...
    > I've included a snippet from Chapter 12 below on Composite Controls:
    >
    > <start>
    >
    > Override the CreateChildControls method to instantiate child controls,
    > initialize them, and add them to the control tree. Do not perform this

    logic
    > in the constructor or in the OnInit method.
    >
    > Let's examine the reason for this implementation detail. You must create
    > your child controls in the CreateChildControls method--instead of creating
    > them in a specific phase such as Instantiate or Initialize--so that

    children
    > can be created on demand when needed in your control's life cycle. This is
    > especially important when you create composite controls whose child

    controls
    > handle postback data.
    >
    > <end>
    >
    > I do not understand this at all. It seems to me that the Init method would
    > be a safe place to initialize the child objects since that method occurs
    > before loading postback data or raising postback events (in the control

    life
    > cycle.) What am I missing here?
    >
    > Much Thanks in advance.
    >
    > Stan
    >
    >
    >
    Pete Beech, Apr 9, 2004
    #2
    1. Advertising

  3. "dx" <> wrote in message
    news:...
    > I have the Microsoft Press: Developing Microsoft ASP.NET Server Controls

    and
    > Components book. It's starting to shine some light on control development
    > but there is something about composite controls that I don't understand...
    > I've included a snippet from Chapter 12 below on Composite Controls:
    >
    > <start>
    >
    > Override the CreateChildControls method to instantiate child controls,
    > initialize them, and add them to the control tree. Do not perform this

    logic
    > in the constructor or in the OnInit method.
    >
    > Let's examine the reason for this implementation detail. You must create
    > your child controls in the CreateChildControls method--instead of creating
    > them in a specific phase such as Instantiate or Initialize--so that

    children
    > can be created on demand when needed in your control's life cycle. This is
    > especially important when you create composite controls whose child

    controls
    > handle postback data.
    >
    > <end>
    >
    > I do not understand this at all. It seems to me that the Init method would
    > be a safe place to initialize the child objects since that method occurs
    > before loading postback data or raising postback events (in the control

    life
    > cycle.) What am I missing here?


    Why do you think you _want_ to initialize the child objects in the Init
    event?

    Child controls should be instantiated when they are needed, and not before.
    You probably don't need them up in the Init event.
    --
    John Saunders
    John.Saunders at SurfControl.com
    John Saunders, Apr 9, 2004
    #3
  4. dx

    Pete Beech Guest

    For viewstate to be loaded into the composite control (assuming each
    subcontrol has it enabled) wouldn't you need to make sure they are created
    in OnInit - either by using EnsureChildControls or creating them explicitly?
    I would think that's a reason to have them created up in the Init event.

    What is the disadvantage of creating the controls explicitly in OnInit,
    assuming the structure of the controls is static and will never change? Why
    is the passage in the book warning against this?

    I'm convinced there must be a good reason for this, but I can't really see
    it..

    Pete

    "John Saunders" <john.saunders at SurfControl.com> wrote in message
    news:...
    > "dx" <> wrote in message
    > news:...
    > > I have the Microsoft Press: Developing Microsoft ASP.NET Server Controls

    > and
    > > Components book. It's starting to shine some light on control

    development
    > > but there is something about composite controls that I don't

    understand...
    > > I've included a snippet from Chapter 12 below on Composite Controls:
    > >
    > > <start>
    > >
    > > Override the CreateChildControls method to instantiate child controls,
    > > initialize them, and add them to the control tree. Do not perform this

    > logic
    > > in the constructor or in the OnInit method.
    > >
    > > Let's examine the reason for this implementation detail. You must create
    > > your child controls in the CreateChildControls method--instead of

    creating
    > > them in a specific phase such as Instantiate or Initialize--so that

    > children
    > > can be created on demand when needed in your control's life cycle. This

    is
    > > especially important when you create composite controls whose child

    > controls
    > > handle postback data.
    > >
    > > <end>
    > >
    > > I do not understand this at all. It seems to me that the Init method

    would
    > > be a safe place to initialize the child objects since that method occurs
    > > before loading postback data or raising postback events (in the control

    > life
    > > cycle.) What am I missing here?

    >
    > Why do you think you _want_ to initialize the child objects in the Init
    > event?
    >
    > Child controls should be instantiated when they are needed, and not

    before.
    > You probably don't need them up in the Init event.
    > --
    > John Saunders
    > John.Saunders at SurfControl.com
    >
    Pete Beech, Apr 9, 2004
    #4
  5. dx

    Scott Guest

    I think you have partially answered your own question; the method EnsureChildControls is tied to
    the idea that child controls will be created in the CreateChildControls; so if you plan on using
    EnsureChildControls, for example in a property of the composite control, you should create the child
    controls in CreateChildControls (because EnsureChildControls will not result in OnInit being called,
    but is will make sure CreateChildControls is called).

    So, when you see something like:

    public string Foobar {
    get { EnsureChildControls(); return Child.Foobar; }
    set { EnsureChildControls(); Child.Foobar = value; }
    }

    Now you are using the facilities provided by the class library; if you create the child controls in
    OnInit, creating property like the above would be trickier (you'd have to eventually get the child
    creation out into a separate method -- which gets you right back to CreateChildControls).

    Of course, the control framework is clever enough to do "catch ups"; so you can create child
    controls in all kinds of places and have it "work"; but if you want take advantage of
    EnsureChildControls (as well as ChildControlsCreated, etc. etc. etc.) you "should" create children
    in CreateChildControls.

    Now, the book also goes on to say that you should also override the Controls collection property;
    and now we are beginning to deal with getting the viewstate up and working.

    My two cents,
    Scott


    "Pete Beech" <> wrote in message
    news:%...
    > For viewstate to be loaded into the composite control (assuming each
    > subcontrol has it enabled) wouldn't you need to make sure they are created
    > in OnInit - either by using EnsureChildControls or creating them explicitly?
    > I would think that's a reason to have them created up in the Init event.
    >
    > What is the disadvantage of creating the controls explicitly in OnInit,
    > assuming the structure of the controls is static and will never change? Why
    > is the passage in the book warning against this?
    >
    > I'm convinced there must be a good reason for this, but I can't really see
    > it..
    >
    > Pete
    >
    > "John Saunders" <john.saunders at SurfControl.com> wrote in message
    > news:...
    > > "dx" <> wrote in message
    > > news:...
    > > > I have the Microsoft Press: Developing Microsoft ASP.NET Server Controls

    > > and
    > > > Components book. It's starting to shine some light on control

    > development
    > > > but there is something about composite controls that I don't

    > understand...
    > > > I've included a snippet from Chapter 12 below on Composite Controls:
    > > >
    > > > <start>
    > > >
    > > > Override the CreateChildControls method to instantiate child controls,
    > > > initialize them, and add them to the control tree. Do not perform this

    > > logic
    > > > in the constructor or in the OnInit method.
    > > >
    > > > Let's examine the reason for this implementation detail. You must create
    > > > your child controls in the CreateChildControls method--instead of

    > creating
    > > > them in a specific phase such as Instantiate or Initialize--so that

    > > children
    > > > can be created on demand when needed in your control's life cycle. This

    > is
    > > > especially important when you create composite controls whose child

    > > controls
    > > > handle postback data.
    > > >
    > > > <end>
    > > >
    > > > I do not understand this at all. It seems to me that the Init method

    > would
    > > > be a safe place to initialize the child objects since that method occurs
    > > > before loading postback data or raising postback events (in the control

    > > life
    > > > cycle.) What am I missing here?

    > >
    > > Why do you think you _want_ to initialize the child objects in the Init
    > > event?
    > >
    > > Child controls should be instantiated when they are needed, and not

    > before.
    > > You probably don't need them up in the Init event.
    > > --
    > > John Saunders
    > > John.Saunders at SurfControl.com
    > >

    >
    >
    Scott, Apr 9, 2004
    #5
  6. dx

    Pete Beech Guest

    I can see how the CreateChildControls/EnsureChildControls mechanism works,
    but I still don't see the point (at least for controls with a fixed set of
    unchanging ChildControls). Assuming no property ever gets called before
    OnInit (which maybe is an assumption which you can't make - although I can't
    see why not), then creating them in OnInit should be adequate.

    So, in your example, if Foobar was always called after the OnInit, there's
    no problem.

    The thing is, the book makes out the creation of controls in OnInit to be
    dangerous - and the only clue is that it "is especially important when you
    create composite controls whose child controls handle postback data.". But
    what exactly is the problem? What wouldn't work if you did it just in
    OnInit? Do the child controls, as part of handling the postback data,
    request that the parent control recreates all its child controls for some
    reason? (maybe I need to use Anakrino)

    It seems, from searching the newsgroups and forums, that a lot of people
    just create their child controls in OnInit anyway, and never have any
    problems.

    Pete

    "Scott" <> wrote in message
    news:ufei$...
    >
    > I think you have partially answered your own question; the method

    EnsureChildControls is tied to
    > the idea that child controls will be created in the CreateChildControls;

    so if you plan on using
    > EnsureChildControls, for example in a property of the composite control,

    you should create the child
    > controls in CreateChildControls (because EnsureChildControls will not

    result in OnInit being called,
    > but is will make sure CreateChildControls is called).
    >
    > So, when you see something like:
    >
    > public string Foobar {
    > get { EnsureChildControls(); return Child.Foobar; }
    > set { EnsureChildControls(); Child.Foobar = value; }
    > }
    >
    > Now you are using the facilities provided by the class library; if you

    create the child controls in
    > OnInit, creating property like the above would be trickier (you'd have to

    eventually get the child
    > creation out into a separate method -- which gets you right back to

    CreateChildControls).
    >
    > Of course, the control framework is clever enough to do "catch ups"; so

    you can create child
    > controls in all kinds of places and have it "work"; but if you want take

    advantage of
    > EnsureChildControls (as well as ChildControlsCreated, etc. etc. etc.) you

    "should" create children
    > in CreateChildControls.
    >
    > Now, the book also goes on to say that you should also override the

    Controls collection property;
    > and now we are beginning to deal with getting the viewstate up and

    working.
    >
    > My two cents,
    > Scott
    >
    Pete Beech, Apr 9, 2004
    #6
  7. dx

    Scott Guest

    Yes; I did say that you could create controls in lots of places, and ASP.NET will play catch-up and
    things will work. When I started writing composite controls, I created all my child controls in
    OnInit or a helper method -- however, this quickly began to break down -- I've given one specific
    case, the forwarding of properties to a child controls. When you start writing designers things get
    more complicated if you don't play along with the control framework.

    Perhaps I should have provided more details about the Foobar property; I can easily see a situation
    when I would instantiate a composite control object and set some properties before I associate the
    control with a parent -- actually, I do this all the time.

    As far as the particular language, it seems a little draconian; and if you really want an answer
    about the authors choice of words I think Nikhil Kothari has a blog someplace -- maybe you can post
    a comment there.

    Scott

    "Pete Beech" <> wrote in message
    news:...
    > I can see how the CreateChildControls/EnsureChildControls mechanism works,
    > but I still don't see the point (at least for controls with a fixed set of
    > unchanging ChildControls). Assuming no property ever gets called before
    > OnInit (which maybe is an assumption which you can't make - although I can't
    > see why not), then creating them in OnInit should be adequate.
    >
    > So, in your example, if Foobar was always called after the OnInit, there's
    > no problem.
    >
    > The thing is, the book makes out the creation of controls in OnInit to be
    > dangerous - and the only clue is that it "is especially important when you
    > create composite controls whose child controls handle postback data.". But
    > what exactly is the problem? What wouldn't work if you did it just in
    > OnInit? Do the child controls, as part of handling the postback data,
    > request that the parent control recreates all its child controls for some
    > reason? (maybe I need to use Anakrino)
    >
    > It seems, from searching the newsgroups and forums, that a lot of people
    > just create their child controls in OnInit anyway, and never have any
    > problems.
    >
    > Pete
    >
    > "Scott" <> wrote in message
    > news:ufei$...
    > >
    > > I think you have partially answered your own question; the method

    > EnsureChildControls is tied to
    > > the idea that child controls will be created in the CreateChildControls;

    > so if you plan on using
    > > EnsureChildControls, for example in a property of the composite control,

    > you should create the child
    > > controls in CreateChildControls (because EnsureChildControls will not

    > result in OnInit being called,
    > > but is will make sure CreateChildControls is called).
    > >
    > > So, when you see something like:
    > >
    > > public string Foobar {
    > > get { EnsureChildControls(); return Child.Foobar; }
    > > set { EnsureChildControls(); Child.Foobar = value; }
    > > }
    > >
    > > Now you are using the facilities provided by the class library; if you

    > create the child controls in
    > > OnInit, creating property like the above would be trickier (you'd have to

    > eventually get the child
    > > creation out into a separate method -- which gets you right back to

    > CreateChildControls).
    > >
    > > Of course, the control framework is clever enough to do "catch ups"; so

    > you can create child
    > > controls in all kinds of places and have it "work"; but if you want take

    > advantage of
    > > EnsureChildControls (as well as ChildControlsCreated, etc. etc. etc.) you

    > "should" create children
    > > in CreateChildControls.
    > >
    > > Now, the book also goes on to say that you should also override the

    > Controls collection property;
    > > and now we are beginning to deal with getting the viewstate up and

    > working.
    > >
    > > My two cents,
    > > Scott
    > >

    >
    >
    Scott, Apr 9, 2004
    #7
  8. dx

    Pete Beech Guest

    Thanks for that - thats a good point, setting properties before adding to
    the parent, when they're forwarded properties. It would be interesting to
    try out some of these controls that have been written using just OnInit to
    see if they do have the kind of problems you mention.

    Cheers,
    Pete

    "Scott" <> wrote in message
    news:...
    >
    > Yes; I did say that you could create controls in lots of places, and

    ASP.NET will play catch-up and
    > things will work. When I started writing composite controls, I created all

    my child controls in
    > OnInit or a helper method -- however, this quickly began to break down --

    I've given one specific
    > case, the forwarding of properties to a child controls. When you start

    writing designers things get
    > more complicated if you don't play along with the control framework.
    >
    > Perhaps I should have provided more details about the Foobar property; I

    can easily see a situation
    > when I would instantiate a composite control object and set some

    properties before I associate the
    > control with a parent -- actually, I do this all the time.
    >
    > As far as the particular language, it seems a little draconian; and if

    you really want an answer
    > about the authors choice of words I think Nikhil Kothari has a blog

    someplace -- maybe you can post
    > a comment there.
    >
    > Scott
    >
    > "Pete Beech" <> wrote in message
    > news:...
    > > I can see how the CreateChildControls/EnsureChildControls mechanism

    works,
    > > but I still don't see the point (at least for controls with a fixed set

    of
    > > unchanging ChildControls). Assuming no property ever gets called before
    > > OnInit (which maybe is an assumption which you can't make - although I

    can't
    > > see why not), then creating them in OnInit should be adequate.
    > >
    > > So, in your example, if Foobar was always called after the OnInit,

    there's
    > > no problem.
    > >
    > > The thing is, the book makes out the creation of controls in OnInit to

    be
    > > dangerous - and the only clue is that it "is especially important when

    you
    > > create composite controls whose child controls handle postback data.".

    But
    > > what exactly is the problem? What wouldn't work if you did it just in
    > > OnInit? Do the child controls, as part of handling the postback data,
    > > request that the parent control recreates all its child controls for

    some
    > > reason? (maybe I need to use Anakrino)
    > >
    > > It seems, from searching the newsgroups and forums, that a lot of people
    > > just create their child controls in OnInit anyway, and never have any
    > > problems.
    > >
    > > Pete
    > >
    > > "Scott" <> wrote in message
    > > news:ufei$...
    > > >
    > > > I think you have partially answered your own question; the method

    > > EnsureChildControls is tied to
    > > > the idea that child controls will be created in the

    CreateChildControls;
    > > so if you plan on using
    > > > EnsureChildControls, for example in a property of the composite

    control,
    > > you should create the child
    > > > controls in CreateChildControls (because EnsureChildControls will not

    > > result in OnInit being called,
    > > > but is will make sure CreateChildControls is called).
    > > >
    > > > So, when you see something like:
    > > >
    > > > public string Foobar {
    > > > get { EnsureChildControls(); return Child.Foobar; }
    > > > set { EnsureChildControls(); Child.Foobar = value; }
    > > > }
    > > >
    > > > Now you are using the facilities provided by the class library; if

    you
    > > create the child controls in
    > > > OnInit, creating property like the above would be trickier (you'd have

    to
    > > eventually get the child
    > > > creation out into a separate method -- which gets you right back to

    > > CreateChildControls).
    > > >
    > > > Of course, the control framework is clever enough to do "catch ups";

    so
    > > you can create child
    > > > controls in all kinds of places and have it "work"; but if you want

    take
    > > advantage of
    > > > EnsureChildControls (as well as ChildControlsCreated, etc. etc. etc.)

    you
    > > "should" create children
    > > > in CreateChildControls.
    > > >
    > > > Now, the book also goes on to say that you should also override the

    > > Controls collection property;
    > > > and now we are beginning to deal with getting the viewstate up and

    > > working.
    > > >
    > > > My two cents,
    > > > Scott
    > > >

    > >
    > >

    >
    >
    Pete Beech, Apr 9, 2004
    #8
  9. dx

    ccallen Guest

    Scott alludes to an important tactic, just try it out and find out where it
    breaks (build up your experience). This is great if periodic downtime is ok.
    However, if downtime on the production machine (due to the control failing)
    is somthing you want to avoid, then the CreateChildControls method is the
    safe bet (from a negligence point of view). Another reason to stick with the
    documented guidelines is that things may change in the next version. Of
    course the documented method could change, but if your on the beta you can
    catch the changes before you customers do.

    ccallen

    "Scott" <> wrote in message
    news:...
    >
    > Yes; I did say that you could create controls in lots of places, and

    ASP.NET will play catch-up and
    > things will work. When I started writing composite controls, I created all

    my child controls in
    > OnInit or a helper method -- however, this quickly began to break down --

    I've given one specific
    > case, the forwarding of properties to a child controls. When you start

    writing designers things get
    > more complicated if you don't play along with the control framework.
    >
    > Perhaps I should have provided more details about the Foobar property; I

    can easily see a situation
    > when I would instantiate a composite control object and set some

    properties before I associate the
    > control with a parent -- actually, I do this all the time.
    >
    > As far as the particular language, it seems a little draconian; and if

    you really want an answer
    > about the authors choice of words I think Nikhil Kothari has a blog

    someplace -- maybe you can post
    > a comment there.
    >
    > Scott
    >
    > "Pete Beech" <> wrote in message
    > news:...
    > > I can see how the CreateChildControls/EnsureChildControls mechanism

    works,
    > > but I still don't see the point (at least for controls with a fixed set

    of
    > > unchanging ChildControls). Assuming no property ever gets called before
    > > OnInit (which maybe is an assumption which you can't make - although I

    can't
    > > see why not), then creating them in OnInit should be adequate.
    > >
    > > So, in your example, if Foobar was always called after the OnInit,

    there's
    > > no problem.
    > >
    > > The thing is, the book makes out the creation of controls in OnInit to

    be
    > > dangerous - and the only clue is that it "is especially important when

    you
    > > create composite controls whose child controls handle postback data.".

    But
    > > what exactly is the problem? What wouldn't work if you did it just in
    > > OnInit? Do the child controls, as part of handling the postback data,
    > > request that the parent control recreates all its child controls for

    some
    > > reason? (maybe I need to use Anakrino)
    > >
    > > It seems, from searching the newsgroups and forums, that a lot of people
    > > just create their child controls in OnInit anyway, and never have any
    > > problems.
    > >
    > > Pete
    > >
    > > "Scott" <> wrote in message
    > > news:ufei$...
    > > >
    > > > I think you have partially answered your own question; the method

    > > EnsureChildControls is tied to
    > > > the idea that child controls will be created in the

    CreateChildControls;
    > > so if you plan on using
    > > > EnsureChildControls, for example in a property of the composite

    control,
    > > you should create the child
    > > > controls in CreateChildControls (because EnsureChildControls will not

    > > result in OnInit being called,
    > > > but is will make sure CreateChildControls is called).
    > > >
    > > > So, when you see something like:
    > > >
    > > > public string Foobar {
    > > > get { EnsureChildControls(); return Child.Foobar; }
    > > > set { EnsureChildControls(); Child.Foobar = value; }
    > > > }
    > > >
    > > > Now you are using the facilities provided by the class library; if

    you
    > > create the child controls in
    > > > OnInit, creating property like the above would be trickier (you'd have

    to
    > > eventually get the child
    > > > creation out into a separate method -- which gets you right back to

    > > CreateChildControls).
    > > >
    > > > Of course, the control framework is clever enough to do "catch ups";

    so
    > > you can create child
    > > > controls in all kinds of places and have it "work"; but if you want

    take
    > > advantage of
    > > > EnsureChildControls (as well as ChildControlsCreated, etc. etc. etc.)

    you
    > > "should" create children
    > > > in CreateChildControls.
    > > >
    > > > Now, the book also goes on to say that you should also override the

    > > Controls collection property;
    > > > and now we are beginning to deal with getting the viewstate up and

    > > working.
    > > >
    > > > My two cents,
    > > > Scott
    > > >

    > >
    > >

    >
    >
    ccallen, Apr 9, 2004
    #9
  10. dx

    Pete Beech Guest

    Thanks, but of course, that's what I always do. In this case since I've
    never had it break it down on me, nor have people like Paul Wilson (see
    http://www.wilsondotnet.com/Tips/ViewPosts.aspx?Thread=278 ). So, here I'm
    just trying to understand the reasoning behind it, and the reasoning given
    in the passage from the book that the original poster quoted. which still
    doesn't make sense to me yet.

    "ccallen" <> wrote in message
    news:...
    > Scott alludes to an important tactic, just try it out and find out where

    it
    > breaks (build up your experience). This is great if periodic downtime is

    ok.
    > However, if downtime on the production machine (due to the control

    failing)
    > is somthing you want to avoid, then the CreateChildControls method is the
    > safe bet (from a negligence point of view). Another reason to stick with

    the
    > documented guidelines is that things may change in the next version. Of
    > course the documented method could change, but if your on the beta you can
    > catch the changes before you customers do.
    >
    > ccallen
    >
    > "Scott" <> wrote in message
    > news:...
    > >
    > > Yes; I did say that you could create controls in lots of places, and

    > ASP.NET will play catch-up and
    > > things will work. When I started writing composite controls, I created

    all
    > my child controls in
    > > OnInit or a helper method -- however, this quickly began to break

    down --
    > I've given one specific
    > > case, the forwarding of properties to a child controls. When you start

    > writing designers things get
    > > more complicated if you don't play along with the control framework.
    > >
    > > Perhaps I should have provided more details about the Foobar property;

    I
    > can easily see a situation
    > > when I would instantiate a composite control object and set some

    > properties before I associate the
    > > control with a parent -- actually, I do this all the time.
    > >
    > > As far as the particular language, it seems a little draconian; and if

    > you really want an answer
    > > about the authors choice of words I think Nikhil Kothari has a blog

    > someplace -- maybe you can post
    > > a comment there.
    > >
    > > Scott
    > >
    Pete Beech, Apr 9, 2004
    #10
  11. "Pete Beech" <> wrote in message
    news:...
    > I can see how the CreateChildControls/EnsureChildControls mechanism works,
    > but I still don't see the point (at least for controls with a fixed set of
    > unchanging ChildControls). Assuming no property ever gets called before
    > OnInit (which maybe is an assumption which you can't make - although I

    can't
    > see why not), then creating them in OnInit should be adequate.


    First the parent control is instantiated, then the properties are set, then
    OnInit gets called. If any parent properties are in any way dependent on
    child controls, or if any child controls are dependent on parent properties,
    then OnInit is too late. This is especially true if the set of child
    controls depends on parent properties.
    --
    John Saunders
    John.Saunders at SurfControl.com
    John Saunders, Apr 11, 2004
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Charles A. Lackman
    Replies:
    1
    Views:
    1,341
    smith
    Dec 8, 2004
  2. SpamProof
    Replies:
    0
    Views:
    547
    SpamProof
    Oct 21, 2003
  3. sleigh
    Replies:
    1
    Views:
    2,685
    sleigh
    Feb 12, 2004
  4. Andrzej J. Turowicz
    Replies:
    1
    Views:
    599
    =?Utf-8?B?RFdT?=
    Jan 29, 2006
  5. Mike

    Composite vs non composite Controls

    Mike, Mar 10, 2005, in forum: ASP .Net Web Controls
    Replies:
    4
    Views:
    261
    Sundararajan
    Mar 11, 2005
Loading...

Share This Page