"Colin Young" <x@nospam.com> wrote in message
news:umMpW0rsDHA.1876@TK2MSFTNGP09.phx.gbl...
> Has anybody ever seen a situation in a custom control where
> CreateChildControls is not being called? I've set a break point in the
> method and it is never hit (in addition, none of the controls that are
> supposed to be created are not being created so I'm reasonably certain it
> isn't just a problem with the debugger not showing the correct code or
> anything like that).

> Thanks
>
> Colin

"Jimmy [Used-Disks]" <noemail@used-disks.com> wrote in message
news:O0gdT8rsDHA.2400@tk2msftngp13.phx.gbl...
> "Colin Young" <x@nospam.com> wrote in message
> news:umMpW0rsDHA.1876@TK2MSFTNGP09.phx.gbl...
> > Has anybody ever seen a situation in a custom control where
> > CreateChildControls is not being called? I've set a break point in the
> > method and it is never hit (in addition, none of the controls that are
> > supposed to be created are not being created so I'm reasonably certain
it
> > isn't just a problem with the debugger not showing the correct code or
> > anything like that).
>
> Are you calling EnsureChildControls() in the right places?
>
> > Thanks
> >
> > Colin
>
> --
> -Jimmy
>
>

"Colin Young" <x@nospam.com> wrote in message
news:uwI%23%23S2sDHA.1680@TK2MSFTNGP12.phx.gbl...
> As far as I can tell. The interesting thing is that the control is
basically
> identical to another control that doesn't call EnsureChildControls()
> anywhere, yet it works.

> My understanding is that I only need to call it if I
> am trying to manipulate the properties of any of the controls that make up
> my control, and since I am not directly manipulating the properties, I
> shouldn't need to call it myself (i.e. the framework will take care of it
> when necessary).

> I've solved the problem by calling EnsureChildControls() in the render
> method.

> Colin

"Jimmy [Used-Disks]" <noemail@used-disks.com> wrote in message
news:uwqMFt2sDHA.2448@TK2MSFTNGP09.phx.gbl...
> "Colin Young" <x@nospam.com> wrote in message
> news:uwI%23%23S2sDHA.1680@TK2MSFTNGP12.phx.gbl...
> > As far as I can tell. The interesting thing is that the control is
> basically
> > identical to another control that doesn't call EnsureChildControls()
> > anywhere, yet it works.
>
> Well, the difference is in there somewhere.
>
> > My understanding is that I only need to call it if I
> > am trying to manipulate the properties of any of the controls that make
up
> > my control, and since I am not directly manipulating the properties, I
> > shouldn't need to call it myself (i.e. the framework will take care of
it
> > when necessary).
>
> I don't beleive so. I could be wrong though.
>
> > I've solved the problem by calling EnsureChildControls() in the render
> > method.
>
> I suggest moving it to the Controls property:
>
> public override Controls{
> get{
> EnsureChildControls();
> return base.Controls;
> }
> }
>
> > Colin
>
> --
> -Jimmy
>
>

"Colin Young" <x@nospam.com> wrote in message
news:u5DGbM4sDHA.3416@tk2msftngp13.phx.gbl...
> It was already in the controls property. That's why I find it so odd that
it
> wasn't working. I've written at least 10 or 15 custom controls and I've
> never had this problem before. Render is the only method that appears to
be
> getting called reliably, although now that I think about it, it may have
> something to do with how I am creating the control and adding it to the
> page. I'm using some old code I wrote when I was first learning the
> framework (in fact before I knew what a custom control was or how to write
> one), so that may be the problem.
>
> Thanks.
>
> Colin
>
> "Jimmy [Used-Disks]" <noemail@used-disks.com> wrote in message
> news:uwqMFt2sDHA.2448@TK2MSFTNGP09.phx.gbl...
> > "Colin Young" <x@nospam.com> wrote in message
> > news:uwI%23%23S2sDHA.1680@TK2MSFTNGP12.phx.gbl...
> > > As far as I can tell. The interesting thing is that the control is
> > basically
> > > identical to another control that doesn't call EnsureChildControls()
> > > anywhere, yet it works.
> >
> > Well, the difference is in there somewhere.
> >
> > > My understanding is that I only need to call it if I
> > > am trying to manipulate the properties of any of the controls that
make
> up
> > > my control, and since I am not directly manipulating the properties, I
> > > shouldn't need to call it myself (i.e. the framework will take care of
> it
> > > when necessary).
> >
> > I don't beleive so. I could be wrong though.
> >
> > > I've solved the problem by calling EnsureChildControls() in the render
> > > method.
> >
> > I suggest moving it to the Controls property:
> >
> > public override Controls{
> > get{
> > EnsureChildControls();
> > return base.Controls;
> > }
> > }
> >
> > > Colin
> >
> > --
> > -Jimmy
> >
> >
>
>

"John Saunders" <john.saunders at SurfControl.com> wrote in message
news:Oa2v2O5sDHA.3532@TK2MSFTNGP11.phx.gbl...
> Maybe you answered this already, but, in what event did you load the
> control?
>
> Also, EnsureChildControls is supposedly called before the PreRender event
> fires.
>
> --
> John Saunders
> John.Saunders at SurfControl.com
>
>
> "Colin Young" <x@nospam.com> wrote in message
> news:u5DGbM4sDHA.3416@tk2msftngp13.phx.gbl...
> > It was already in the controls property. That's why I find it so odd
that
> it
> > wasn't working. I've written at least 10 or 15 custom controls and I've
> > never had this problem before. Render is the only method that appears to
> be
> > getting called reliably, although now that I think about it, it may have
> > something to do with how I am creating the control and adding it to the
> > page. I'm using some old code I wrote when I was first learning the
> > framework (in fact before I knew what a custom control was or how to
write
> > one), so that may be the problem.
> >
> > Thanks.
> >
> > Colin
> >
> > "Jimmy [Used-Disks]" <noemail@used-disks.com> wrote in message
> > news:uwqMFt2sDHA.2448@TK2MSFTNGP09.phx.gbl...
> > > "Colin Young" <x@nospam.com> wrote in message
> > > news:uwI%23%23S2sDHA.1680@TK2MSFTNGP12.phx.gbl...
> > > > As far as I can tell. The interesting thing is that the control is
> > > basically
> > > > identical to another control that doesn't call EnsureChildControls()
> > > > anywhere, yet it works.
> > >
> > > Well, the difference is in there somewhere.
> > >
> > > > My understanding is that I only need to call it if I
> > > > am trying to manipulate the properties of any of the controls that
> make
> > up
> > > > my control, and since I am not directly manipulating the properties,
I
> > > > shouldn't need to call it myself (i.e. the framework will take care
of
> > it
> > > > when necessary).
> > >
> > > I don't beleive so. I could be wrong though.
> > >
> > > > I've solved the problem by calling EnsureChildControls() in the
render
> > > > method.
> > >
> > > I suggest moving it to the Controls property:
> > >
> > > public override Controls{
> > > get{
> > > EnsureChildControls();
> > > return base.Controls;
> > > }
> > > }
> > >
> > > > Colin
> > >
> > > --
> > > -Jimmy
> > >
> > >
> >
> >
>
>

"Colin Young" <x@nospam.com> wrote in message
news:uUxfw55sDHA.3196@TK2MSFTNGP11.phx.gbl...
> Well, see, that was the problem. As I said, I was using some page
templating
> code I wrote way back when I was just learning .Net, and prior to learning
> custom controls properly. It turns out that in my template code I only
made
> use of "special" custom controls because I was only calling the Render
> method, rather than adding the custom control to the control tree for the
> page.
>
> It just tells me it's time to revisit my header control and fix it.

"John Saunders" <john.saunders at SurfControl.com> wrote in message
news:eRgpuL6sDHA.2132@TK2MSFTNGP10.phx.gbl...
> "Colin Young" <x@nospam.com> wrote in message
> news:uUxfw55sDHA.3196@TK2MSFTNGP11.phx.gbl...
> > Well, see, that was the problem. As I said, I was using some page
> templating
> > code I wrote way back when I was just learning .Net, and prior to
learning
> > custom controls properly. It turns out that in my template code I only
> made
> > use of "special" custom controls because I was only calling the Render
> > method, rather than adding the custom control to the control tree for
the
> > page.
> >
> > It just tells me it's time to revisit my header control and fix it.
>
> Colin, that sounds familiar!
>
> FYI, in case you didn't know, the next version of ASP.NET (in the
"Whidbey"
> release) will include a built-in page templating technology (master
pages).
> I've played with it a bit, and it looks pretty cool.
>
> In particular, if one currently has "content" which is stored in user
> controls, it should be easy to adapt this content for use with master
pages.
> This made me feel _much_ better, since my page templating code uses user
> controls both for the content and for the "master".
> --
> John Saunders
> John.Saunders at SurfControl.com
>
>