Invalid character in a Base-64 string 1

[Chopstik]

I have a page that I am using with JQuery/Ajax (at this point, I'm not sure what is what) that works fine up until the point that I attempt to do a postback from a dropdown box. Then, it blows up on me with the following message:

Complete Error Text: System.Web.HttpException: The state information is invalid for this page and might be corrupted. ---> System.Web.UI.ViewStateException: Invalid viewstate.

In short, I have a main page (Welcome) that then calls three other pages (three different charts) to be run inside. In the Welcome page, I use the following to call them:

   1.            <script type="text/javascript">
   2.                 function getQSVar() {
   3.                     var url = window.location.href;
   4.                     var params = url.split('?');
   5.                     return params[1];
   6.           }
   7.  
   8.           $(document).ready(function() {
   9.               var myUrl = "?" + getQSVar();
  10.               $("#ctl00_body_divChart1").load("Controls\\ErrorTrendChart.aspx" + myUrl);
  11.               $("#ctl00_body_divChart2").load("Controls\\UploadSummaryChart.aspx" + myUrl);
  12.               $("#ctl00_body_divChart3").load("Controls\\PayerResponseChart.aspx" + myUrl);
  13.           });
  14.             </script>

My dropdown looks like this:

   1. <asp:DropDownList ID="ddlPayer" Runat="server" AutoPostBack="true" Width="70%" EnableViewState="false"
   2.                                                                                 style="font-family:Trebuchet MS, Arial, Helvetica, Sans-Serif; font-size: 8pt; font-weight: bold;"
   3.                                                                                 onselectedindexchanged="ddlPayer_SelectedIndexChanged"></asp:DropDownList>

I've disabled ViewState both at the page level and the control level in each of the three Chart pages (in each of the pages, there is only a single <div> tag with the codebehind that actually generates the relevant charts). My initial research indicates that the problem may have something to do with the AJAX opening of the three charts inside of the Welcome page but I don't see a way around it other than disabling the ViewState. Anyone else come across this before or have suggestions on how to resolve?

------------------------------------------------------------------------------------------------------------------------
Reason and free inquiry are the only effectual agents against error; they are the natural enemies of error and of error only.

Thomas Jefferson

http://lessthandot.com

 

[jbenson001]

Have you turned off the viewstate for ALL of the controls, including the ddl?

 

[jmeckley]

I believe the problem is viewstate validation, which is independent of storing viewstate. the MS Ajax cascade dropdowns had the same issue.

set [tt]EnableEventValdation = false[/tt] to allow dynamic values on postback

Jason Meckley
Programmer

faq855-7190
faq732-7259

 

[Chopstik]

jbenson001, I have disabled viewstate in the page directive and the single <div> tag that exists in each of the three pages being called. I have disabled viewstate in the page directive and the ddl of the calling page (Welcome.aspx), but none of the other controls that exist on that page.

jmeckley, I tried that on all of the pages (Welcome and the three chart pages) but no joy.

In my research, I came across something that indicated a problem whereby there was a variable name in one (or maybe all) of the charts called "__VIEWSTATE" which then replaced the same value on the main page and that this could be causing my issue. However, I'm not sure how to test that and, if so, what I can do to stop it. The recommendation in that thread was to either change the AJAX page to use HTML controls (which not sure I can do because of how to render the charts) or to move the elements from the AJAX page to the main page (which defeats the purpose of creating this way in order to asynchronously generate the charts and thus prevent potential failures to the main page due to timeouts on the charts themselves). Not sure if there is another workaround or a better explanation to the problem...

------------------------------------------------------------------------------------------------------------------------
Reason and free inquiry are the only effectual agents against error; they are the natural enemies of error and of error only.

Thomas Jefferson

http://lessthandot.com

 

[jmeckley]

viewstate is a hidden field generated by webforms. each page has a viewstate hidden field. if you are loading the entire webpage from ajax, then you would have conflict here because you have multiple controls with an id of viewstate. try loading the pages in an iframe. this may resolve the viewstate issue. otherwise you need to alter what is returned by the ajax call.

Jason Meckley
Programmer

faq855-7190
faq732-7259

 

[Chopstik]

I can't really use an iframe here because the three charts are all specifically placed on the page and can't be changed. The three pages being loaded are being all loaded, not just sections of them - which is what I understand you are saying about the conflicts with multiple controls with an id of viewstate.

So, that being the case, what do you mean by altering what is returned by the ajax call?

------------------------------------------------------------------------------------------------------------------------
Reason and free inquiry are the only effectual agents against error; they are the natural enemies of error and of error only.

Thomas Jefferson

http://lessthandot.com

 

[jmeckley]

so set the iframe accordingly it's not that much different other than you load a page into a sub frame instead of the main frame. this would be the simplest solution given your current setup.

don't return the entire page rendered by the page object, only return the part you (the end user) requires (which is different than what webforms may require).

some other things to think about.
1. webforms is not ajax friendly. it's possible, but not easily.
2. place the chart on the main page, removing the need for ajax altogether.
3. what you want may not be possible with ajax and webforms. at best you might be able to place the chart on the main form and wrap it in an update panel, but that seems more like a hack than anything else.

Jason Meckley
Programmer

faq855-7190
faq732-7259

 

[Chopstik]

I'll play with the iframe idea and see if I can get it to work. If not, I'll have to scrap this and try something else completely - but it's annoying because everything else worked perfectly except for this idiot postback problem. *sigh*

Regarding your other point, I actually had to move the charts off of the main page because they didn't always load within the timeout period and therefore blew up the entire page (not good on a welcome page). Now if they blow up, I can limit it to just the chart itself. So if I can't use this, it seems like my choices are limited, at best. I really dislike having to hack these things together, though...

Thanks for your help!

------------------------------------------------------------------------------------------------------------------------
Reason and free inquiry are the only effectual agents against error; they are the natural enemies of error and of error only.

Thomas Jefferson

http://lessthandot.com

 

[jmeckley]

everything else worked perfectly except for this idiot postback problem.....
I really dislike having to hack these things together, though...

that's webforms

I actually had to move the charts off of the main page because they didn't always load within the timeout period

have you determined where the bottleneck is? moving the reports off the screen doesn't fix the problem. it only delays it. solving this problem may allow you to display the reports on the main page.

Jason Meckley
Programmer

faq855-7190
faq732-7259

 

[Chopstik]

The bottleneck is actually retrieving the data from the DB - it keeps timing out for certain clients due to the size of the data. We had contemplated increasing the timeout to resolve the issue but with the way our data access layer is configured, it would mean that the timeout changes for all calls - it can't be limited to just these particular ones. That's why we were trying to move them off separately...

Oh well... To quote a friend of mine - "Software development. If it were easy, it would be called football."

Thanks for your help!

------------------------------------------------------------------------------------------------------------------------
Reason and free inquiry are the only effectual agents against error; they are the natural enemies of error and of error only.

Thomas Jefferson

http://lessthandot.com

 

[Chopstik]

To follow up with this, I ended up doing a different kind of workaround. Instead of posting the page when the selected index of the drop down is changed, I handled it client-side so that it will use JQuery to then reload the needed sub-pages when the selected index was changed. This actually seems to work rather well. Just in case anyone else ever comes across this issue. It may not work for everyone but it is an option.

I may well have been able to use an iframe but I was pretty far along with this line of thought an wanted to prove it out before I ditched it all and tried it. If I've time later (not a good likelihood), I may try it and see what happens. Thanks again for your help, jmeckley!

------------------------------------------------------------------------------------------------------------------------
Reason and free inquiry are the only effectual agents against error; they are the natural enemies of error and of error only.

Thomas Jefferson

http://lessthandot.com