Page_Load -> Page_Init

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

Please do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.

This forum is for discussing mojoPortal development

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

You can monitor commits to the repository from this page. We also recommend developers to subscribe to email notifications in the developer forum as occasionally important things are announced.

Before posting questions here you might want to review the developer documentation.

Do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.
This thread is closed to new posts. You must sign in to post in the forums.
12/8/2006 10:53:29 PM
Gravatar
Total Posts 488

Page_Load -> Page_Init

I have noticed that in mojoPortal code most of operations like setting strings from resources to module controls are performed in Page_Load().
And all of them are performed on each postback.
Why not moving them to Page_Init()?
12/9/2006 2:56:39 AM
Gravatar
Total Posts 18439

Re: Page_Load -> Page_Init

In Page_Init, you should not access server controls unless you first instantiate them yourself because there is no guarantee that they have been created yet.

Page_Load is the correct place to call methods that set server control properties for server controls that are added to the page declaratively.

Labels must also be populated on postback unless they use viewstate, I'm not using viewstate in a lot of places.

Joe
12/9/2006 3:13:29 AM
Gravatar
Total Posts 488

Re: Page_Load -> Page_Init

http://msdn2.microsoft.com/en-us/library/ms178472.aspx

"Init: Raised after all controls have been initialized and any skin settings have been applied. Use this event to read or initialize control properties."
12/9/2006 3:21:06 AM
Gravatar
Total Posts 18439

Re: Page_Load -> Page_Init

Well it looks like that page does indicate that all controls have been initialized. However it doesn't say that is a good place to set properties of child controls, and in fact says "Use the OnLoad event method to set properties in controls and establish database connections."

This article says there is no guarantee in Page_Init that child controls are created, though I would tend to believe MSDN.
http://www.dotnet4all.com/Dot-Net-Books/2004/08/difference-between-pageload-and.html

Still I can't see a good reason to move the setting of labels to Page_Init. Whats the benefit? The code is working fine as is.
12/9/2006 4:01:40 AM
Gravatar
Total Posts 488

Re: Page_Load -> Page_Init

You seem to be right:

http://msdn2.microsoft.com/en-us/library/system.web.ui.control.init.aspx
"Server controls should perform any initialization steps that are required to create and set up an instance."
"
You should not access another server control during this event, regardless of whether it is a child or parent to this control. Other server controls are not certain to be created and ready for access."

As far as you know, Page is also System.Web.UI.Control.
So, in Page_Init the page itself is guaranteed to be initialized, but all the child controls are not. They are only when Page.InitComplete event is raised.

I did not know this - I used Page_Init to initialize page controls in many projects and never had problems. May be, it is implementation specific (all these projects were Windows-based).


The reason to move setting of labels to Page.InitComplete (not Page.Init) event hadler is that in this case this code will not be executed on postbacks with no need of viewstate.
Of course, the code is working now. But not in the most efficient way. :)
You must sign in to post in the forums. This thread is closed to new posts.