CreateChildControls executes on initial load and at postback?

[paul reed]

Hello,

I have a composite control I have built. I capture a click event of a tree
control then raise my own event along with a custom args object for the
server-side to deal with. All the plumbing seems to work just fine. However,
I noticed, while in debug, that the CreateChildControls method gets invoked
at initial load time, as expected, but also when I click on my tree node. It
executes the CreateChildControls method again before executing my handler
logic that captures the click event.

Is there something I need to do like is done for multiple postbacks to an
aspx page (e.g., If NOT PageIsPostback) or something like that to avoid this
double execution of this method?

Thanks,

Paul

[Jeffrey Tan[MSFT]]

Hi Paul,

Thank you for posting in the community!

Based on my understanding, you create composite control in Web Form, your
control contains TreeView web control. When you click treenode of your
treeview control, the CreateChildControls method executes before the Click
event of your treenode control.

========================================================
Based on your statement, I think you set the TreeView's AutoPostBack
property to true, so each time you click treenode, the whole web form
postback to server side.

The CreateChildControls method is used to create all the child controls.
Before you manipulate the control's properties and events, you should
always make sure that all the child controls is created. You can achieve
this through EnsureChildControls method. This method will invoke the
CreateChildControls method to create all the child controls.

In Asp.net WebForm's event model, for composition control, it will load the
default items based in the CreateChildControls method at Init event.(Which
is the first event)

So CreateChildControls method is always fires before any other customized
child control event. This is by the design of Asp.Net WebForm event model.

You can find more information in some articles:
http://aspalliance.com/articleViewer.aspx?aId=345&pId=-1
http://www.codeproject.com/aspnet/composite_controls.asp

Can you show me your real obstacles?
Maybe I can help you create a better structure to workaround.

========================================================
Thank you for your patience and cooperation. If you have any questions or
concerns, please feel free to post it in the group. I am standing by to be
of assistance.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Paul Reed]

Jeffrey,

Thanks for your help. I think I understand your points and Nic's article
you referred me to wass great. However, I think I am doing everything
just fine. Here are my issues:

1. When I run under debug, I can see my control being created correctly
in the CreateChildControls method. I then access a database, get the
data for my treeview and load it. I also wire up an event handler to
deal with the click event of the node because I want to raise a custom
even back to the client. This all appears to work just fine.

2. I do want the form to post back when a certain tree node is
clicked...at postback time, I notice that prior to my event getting
raised, the CreateChildControls method fires yet again, prior to the
click event happening. In the end, my aspx page does get the custom even
raised and I am able to assess which node was selected...but why does
the CreateChildControls method fire on postback prior to my event
getting handled?

Paul Reed
www.jacksonreed.com

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Christian Falch]

Hi,

Paul Reed wrote:
> 2. I do want the form to post back when a certain tree node is
> clicked...at postback time, I notice that prior to my event getting
> raised, the CreateChildControls method fires yet again, prior to the
> click event happening. In the end, my aspx page does get the custom even
> raised and I am able to assess which node was selected...but why does
> the CreateChildControls method fire on postback prior to my event
> getting handled?

Because your objects aren't persistet through subsequent calls to your
webforms :-). This is how the asp.net runtime ensures that your control
hierarchy is available when calling your event handlers. Here is a
description of what happens:

1) A client webbrowser sends a request to your webserver to view a webform.

2) Your webform is built and your control and it's subcontrols are
created. Subcontrols are created by calling your control's
CreateChildControls() method. The resulting HTML is sent back to the client.

3) The user clicks on a postback link on the webform in his/hers browser
and the browser sends the postback data to your server.

3) The server recieves the request, and to be able to process the
request (ie. present the webform to the user and respond to events), the
webform must be created. Creating your webform includes the same steps
as described under section 1, this is why your CreateChildControls()
method is called on postback.

Hope this explained what's happening.

--
Chris

[Jeffrey Tan[MSFT]]

Hi Paul,

Thanks very much for your feedback. I am glad I can help you :-)

For your further concern, I will explain it for your.

============================================
In .Net Web Form application, because of the Http stateless, all the .Net
objects will only existed at server side.
So each time the Web Form renderred to the client, all the objects will be
disposed. While the client postback to the server, all the objects will be
created again.

The server side event(Such as TreeNode's SelectedIndexChange event) is
associated with the object, so its can only be handled after the objects
have been(That is CreateChildControls method).

Thats why CreateChildControls method fires prior to the treenode event.

Also, I want to note you that, the Server side event is handled through
IPostBackEventHandler interface.(You can view the IPostBackEventHandler in
the object lifecycle model's position)

For an example of Server side event handling, please refer to:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconPostbackEventSample.asp

============================================
Hope all these help you. If you still have any further concern, please feel
free to post, I will help you.

[Paul Reed]

Jeffrey,

One more question...thanks.

Let's say you have a composite control with two text boxes. Let's also
say that you initialize these conrtrols to a default value prior to have
the control presented to the client in the browser. Let's now say the
user changes one of those text boxes. How is it then that at post back
time, if CreateChildControls get's fired again, you don't end up
resetting that text box to its default value again prior to getting the
new value that the user just keyed in?

I am very comfortable with the postback behavior in an ASPX page, and I
am very comfortable that at Page_Load time you can say IF Not
(Me.IsPostBack)...to prevent doing just what I am describing, reloading
of list boxes and default values. If it is a subsequent post back, the
page can act accordingly and NOT do something that should only be done
on the first execution of Page_Load. I don't know if I am making sense
or not. I just expected the same thing with the composite control.

Thanks again.

[Jeffrey Tan[MSFT]]

Hi Paul,

Thanks for your feedback.

For your post, I am not sure of the meanning of "How is it then that at

post back time, if CreateChildControls get's fired again, you don't end up
resetting that text box to its default value again prior to getting the new
value that the user just keyed in?"

Based on my understanding, your question is: In composite control's
postback time, CreateChildControls fires, so it initializes all the child
controls to their default value. How does the composite control get its
child controls' NEW value. (That is: the value that entered at client
side). If I misunderstand you, please feel free to tell me.

============================================================
Actually, no matter postback or not, the CreateChildControls method will be
called. For composite control, the load and maintenance of postback data is
not due to the composite control, but by its child controls themselves,
such as TextBox.
The TextBox control implement the IPostBackDataHandler interface, which
defines methods that ASP.NET server controls must implement to
automatically load post back data.

There are 2 methods in IPostBackDataHandler interface: LoadPostData and
RaisePostDataChangedEvent.
1). LoadPostData is used to processes post back data for an ASP.NET server
control.
2). RaisePostDataChangedEvent is used to signal the server control object
to notify the ASP.NET application that the state of the control has changed.

There is a postback data handling sample in the document, please refer to:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfsystemwebuiipostbackdatahandlerclasstopic.asp

In Control Execution Lifecycle, LoadPostData will be called after the
CreateChildControls method. In the document sample , you will see that: in
LoadPostData method, it will judge if the textbox's value has been changed.
If the value changed, it will retrieve the new value(Which will overwrite
the default value that being set in CreateChildControls method).

I think this fully explains the process of the postback data handling.

Note: Only the data related server side control need to implement this
IPostBackDataHandler interface.

============================================================
Hope I explains it clear. If you have anything unclear, please feel free to
tell me.
Have a nice day!!

[Paul Reed]

Jeffrey,

Thanks so much, this last piece of information is what clarified
everything for me.

Best wishes....Paul

[Jeffrey Tan[MSFT]]

Hi Paul,

Thanks for your feedback. I am glad I can help you :-)

The Asp.net lifecycle model is important for server side programming. I am
glad I have clarified it.

If you have further concern, please feel free to post, I will work with you.