tags:

views:

34

answers:

2

In object-oriented languages, if class A contains class B as a member, you can access class B's properties from class A's constructor (after you instantiate class B first).

However in ASP.Net, my understanding is that a Page object contains server control objects as its members, but I do not understand why, if you try to access a server control's properties from the Page constructor, you get a NullReferenceException.

+3  A: 

In the constructor, the ASPX has not run yet, so all of the server-side controls are null.

Move your code to Page_Load.

SLaks
The server control objects are created when their constructors are called by the Page's constructor! These objects are not created later. By right they should be available from Page constructor.
Aperture
Surely moving to later events would work, but I would like to push the theoritical boundries.
Aperture
If you want to get all theoretical, learn about the Page lifecycle, and then start writing your own child control instantiation code in the Page constructor or where ever you like. But that's not how ASP.NET does it itself.
Andrew Barber
@User: Wrong. They aren't called by the constructor, but by the `ProcessRequest` method, which is called by ASP.Net.
SLaks
+4  A: 

It sounds more like a Life Cycle problem. The controls contained on your page is not created at the same time as your Page object, but later in the cycle of your httprequest.

This page gives a clear picture of the cycle: http://msdn.microsoft.com/en-us/library/ms178472.aspx.

You should instead override the Init-method to be sure your controls are initialized. Quote from the article

Raised after all controls have been initialized and any skin settings have been applied. The Init event of individual controls occurs before the Init event of the page. Use this event to read or initialize control properties.

BurningIce
The server control objects are created when their constructors are called by the Page's constructor! These objects are not created later.
Aperture
I'm not i'm sure following you... servercontrols (tags with runat="server") are not necessarily created when the page's constructor is called. I would never depend on it and recommends that code that relies on child-controls to be created is written so it takes the Page Life Cycle into account.
BurningIce
@BurningIce: Let's say we have a UserControl (like a mini aspx page), which contains server controls. If you can only access these server controls from the UserControl.Load event, it can be problematic, because future pages using this user control would not be able to access the child server controls before the UserControl_Load event. Then people would have to guess just when these server controls becomes available. You see, uncertainty is not good...
Aperture
Uncertainty is **not** good, correct. But if you were to study the ASP.NET Page Lifecycle page that was linked above, you would not be uncertain any more.
Andrew Barber
@Andrew Barber: The uncertainty is always there because a custom composite server control's author can arbitrarily put programming logic in any of the Init, Load, PreRender event handlers. If you use the custom control, you would have to guess when certain child controls becomes available...
Aperture
Whenever you call someone else's code, you need to become aware of what it does and when. Again: Read that page!! It explains the typical differences for example with dynamically created controls, and composite controls.
Andrew Barber