Welcome Guest Search | Active Topics | Sign In | Register

problems with viewstate with callback panel Options
Geary
Posted: Wednesday, August 22, 2007 12:02:45 PM
Rank: Newbie
Groups: Member

Joined: 6/22/2007
Posts: 2
I have a webpage where I have a couple textboxes, an 'add' button and web server table control inside a callback panel. The intention is for the user to enter data for a new record in the textboxes and then click the 'add' button to add it to the table control. I added the callback panel around the table control to prevent a post back when new records are added. And it works as far that goes. The problem is that when I add a 2nd, 3rd, 4th record, etc...it doesn't retain the previous record. It only keeps the new one. I realize this has to do with the statelessness of web app. I dug into the viewstate object. I have enabled viewstate on both the table control and the callback panel without success.
Any ideas what I need to try next? And yes, I am a relative newbie. But I imagine this type of arrangement is not unique.
eo_support
Posted: Wednesday, August 22, 2007 12:25:34 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,088
Hi Geary,

Thanks for posting your question here. This is a very common web development scenario and it actually does not have anything to do with our CallbackPanel. You would get the same result with or without our CallbackPanel control.

To understand why it happens this way, it's important to understand how view state works. View state does not automatically saves everything. View state is a piece of information associated with a control, so it won't live without the control. Considering the following example:

1. Page1.aspx statically declares control A, B, it renders initially and view state information for A and B are rendered to the client;
2. Some code behind logic dynamically creates control C, now A, B and C's view state information are rendered to the client;
3. The page posts back. ASP.NET reconstructs a page from Page1.aspx, now it only has A and B. Even though C's view state information is posted back, it can not find its "host" control to stick on. This information is thus discarded;

However, if your code recreates control C on step 3 before ASP.NET loads view state (recreate them in Page_Init), control C's view state information will find the newly created control and associates with it.

The key at here is that view state saves changes to a control's property, it does not save changes to the control tree itself.

In order to solve the problem, you must reconstruct the control tree. A easy way to save all "items" in the page's view state (for instance, you can save all items in an ArrayList and save that whole ArrayList in view state), you will then reconstruct your Table based on that ArrayList every time inside your Page_Load. Since the Page object (which is the root control of the control tree) is always there, so the information won't be discarded.

Let us know if you still need more help.

Thanks
Geary
Posted: Wednesday, August 22, 2007 12:35:56 PM
Rank: Newbie
Groups: Member

Joined: 6/22/2007
Posts: 2
Ok...that makes sense. If I understand what you are saying correctly...enabling viewstate is not enough. I still need to write code to specifically save the data and then recreate it.

So this leads to the next question. Since I AM using a Callback panel to prevent a postback, where do I put the code to recreate the control? Since there is no postback, I doubt if there's a page_load event. Does the Callback Panel raise an event that I should use? Or should I be looking at events raised by the table control?
eo_support
Posted: Wednesday, August 22, 2007 12:48:00 PM
Rank: Administration
Groups: Administration

Joined: 5/27/2007
Posts: 24,088
Hi Geary,

The CallbackPanel does not eliminate/prevent the page from posting back. The whole page is still posted back, however instead of updating the whole page after post back, it only updates the region that's inside the CallbackPanel. So Page_Load is always fired.

In fact one of the main design goal for the CallbackPanel control is to make it work "as if" it does not exists. Which means you do not need to change your code logic to "accomodate" our CallbackPanel control. Everything is still the same ---- Page_Load still get fired, Button_Click still get fired, etc. The only difference is instead of the whole page being updated, only the portion that's inside the CallbackPanel is being updated.

Thanks


You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.