1) I have a problem where I'm declaring an object variable outside an event i.e.
public partial class _Default : System.Web.UI.Page
{
public MyObject myObject;
}
2) I am then instantiating it as part of a Button 'Click' event i.e.
protected void buttonStart_Click(object sender, EventArgs e)
{
myObject = new MyObject(textBox1.Text, new string[] { "Hello", "Hi" }, TextBox3);
}
3) The object is instantiated fine within the above event, & the rest of the code within that event uses the object fine (so, seems okay).
4) Problem: When I go to use the object outside of the event, I receive a 'Object reference not set to an instance of an object' exception. (This after the event 'has' occured.)
5)
a. As far as I know I have properly added a reference to the namespace in which the object as a class resides.
b. I have added a using statement for this namespace correctly.
c. I think this is all confirmed by the fact that the object is instantiated & works fine in the first event which instantiates it.
6) All this is taking place in my 'Default.aspx.cs' file.
Thanks so much Oned. Is that standard practice for ASP.NET, that an object’s state is not stored in memory & so that ViewState must be used?
I’m a C# desktop developer & new to ASP.NET, I understand about how the web doesn’t maintain state though. However, I’d thought that objects used this way in C# would be maintained as they were on the server?
Is that not so though?
Must a separate process such as ViewState be used? I assume if so, it must be done each time a Post Back is made?
Is this the problem? With each Post Back are your objects lost?
Thanks once again & sorry for the late reply - very busy I'm afraid.
I've checked that out :)
The link talks mainly about persisting controls using ViewState, is it the same with custom C# objects? i.e. Must they be persisted in ViewState in exactly the same way?
"At the end of the pipeline, a class corresponding to the requested ASP.NET Web page
is instantiated and the ProcessRequest() method is invoked (see Figure 1)." (my emphasis)
That means for every incoming request from the browser, even a postback to the same page, a crispy, shiny, brand new ASP.NET Page object is going to be created. Which means that every single field, including all of your custom C# objects, will be initialised
to their default value - which as you know is null for reference types.
So yes, you need to manage the state for those objects yourself, either by persisting it in ViewState, or Session, or Cookies, or the query string, or even in Profile. There are a lot of pitfalls with managing state - query string is weak due to the
way users share links, bookmark things, edit them!, etc.
Hidden fields, such as ViewState, can be tampered with (there are ways of reducing the risk here)
Session requires careful management, especially in the face of web farming.
And security is always nagging away at us.
This is a tricky area, but you really need to try to design as stateless a system as you can manage. Remember, the user is expecting a slick solution, after all.
To conclude. You have to manage state. There are a number of ways to do it, all with various pros and cons.
And I don't know whether this is a consolation or not, but there is a dedicated forum here on state management, and it is often quite busy!
Regards
Dave
Marked as answer by Dan29 on Dec 19, 2012 05:11 PM
Dan29
Member
17 Points
65 Posts
Declaring object variable outside event - only instantiating in event - object doesn't exist outs...
Dec 14, 2012 07:12 AM|LINK
Hi guys,
I wonder if anyone can help?
1) I have a problem where I'm declaring an object variable outside an event i.e.
public partial class _Default : System.Web.UI.Page
{
public MyObject myObject;
}
2) I am then instantiating it as part of a Button 'Click' event i.e.
protected void buttonStart_Click(object sender, EventArgs e)
{
myObject = new MyObject(textBox1.Text, new string[] { "Hello", "Hi" }, TextBox3);
}
3) The object is instantiated fine within the above event, & the rest of the code within that event uses the object fine (so, seems okay).
4) Problem: When I go to use the object outside of the event, I receive a 'Object reference not set to an instance of an object' exception. (This after the event 'has' occured.)
5)
a. As far as I know I have properly added a reference to the namespace in which the object as a class resides.
b. I have added a using statement for this namespace correctly.
c. I think this is all confirmed by the fact that the object is instantiated & works fine in the first event which instantiates it.
6) All this is taking place in my 'Default.aspx.cs' file.
Any ideas anyone?
Thanks very much indeed,
Dan.
oned_gk
All-Star
30991 Points
6344 Posts
Re: Declaring object variable outside event - only instantiating in event - object doesn't exist ...
Dec 14, 2012 07:23 AM|LINK
Store it in viewstate
Similar Session but only for current page.
Dan29
Member
17 Points
65 Posts
Re: Declaring object variable outside event - only instantiating in event - object doesn't exist ...
Dec 14, 2012 05:02 PM|LINK
Hi,
Thanks so much Oned. Is that standard practice for ASP.NET, that an object’s state is not stored in memory & so that ViewState must be used?
I’m a C# desktop developer & new to ASP.NET, I understand about how the web doesn’t maintain state though. However, I’d thought that objects used this way in C# would be maintained as they were on the server?
Is that not so though?
Must a separate process such as ViewState be used? I assume if so, it must be done each time a Post Back is made?
Is this the problem? With each Post Back are your objects lost?
Thanks so much again,
Dan :)
oned_gk
All-Star
30991 Points
6344 Posts
Re: Declaring object variable outside event - only instantiating in event - object doesn't exist ...
Dec 15, 2012 02:27 AM|LINK
http://msdn.microsoft.com/en-us/library/ms972976.aspx
Dan29
Member
17 Points
65 Posts
Re: Declaring object variable outside event - only instantiating in event - object doesn't exist ...
Dec 18, 2012 05:48 PM|LINK
Hi Oned,
Thanks once again & sorry for the late reply - very busy I'm afraid.
I've checked that out :)
The link talks mainly about persisting controls using ViewState, is it the same with custom C# objects? i.e. Must they be persisted in ViewState in exactly the same way?
Thanks,
Dan :)
DMW
All-Star
15943 Points
2353 Posts
Re: Declaring object variable outside event - only instantiating in event - object doesn't exist ...
Dec 19, 2012 04:45 AM|LINK
Dan
The key sentence in the article is
"At the end of the pipeline, a class corresponding to the requested ASP.NET Web page is instantiated and the
ProcessRequest()method is invoked (see Figure 1)." (my emphasis)That means for every incoming request from the browser, even a postback to the same page, a crispy, shiny, brand new ASP.NET Page object is going to be created. Which means that every single field, including all of your custom C# objects, will be initialised to their default value - which as you know is null for reference types.
So yes, you need to manage the state for those objects yourself, either by persisting it in ViewState, or Session, or Cookies, or the query string, or even in Profile. There are a lot of pitfalls with managing state - query string is weak due to the way users share links, bookmark things, edit them!, etc.
Hidden fields, such as ViewState, can be tampered with (there are ways of reducing the risk here)
Session requires careful management, especially in the face of web farming.
And security is always nagging away at us.
This is a tricky area, but you really need to try to design as stateless a system as you can manage. Remember, the user is expecting a slick solution, after all.
To conclude. You have to manage state. There are a number of ways to do it, all with various pros and cons.
And I don't know whether this is a consolation or not, but there is a dedicated forum here on state management, and it is often quite busy!
Dave
Dan29
Member
17 Points
65 Posts
Re: Declaring object variable outside event - only instantiating in event - object doesn't exist ...
Dec 19, 2012 05:11 PM|LINK
Excellent, thanks Dave that's great. It's exactly the answer to that which I was pondering :)
Thanks for taking the time once again, it's a big help :)
Dan :)