error in viewstate on submit to iframe through js

L

lamy

Regular
Joined
Dec 12, 2005
Messages
56
Location
under your bed
in my javascript i have this
Code: 
function submitToFrame(url)
   {
   var frm = document.forms[0];
   frm.target = "myIFrame";
   frm.action = url;
   frm.submit();
   return false;
   }

and a submit button with this attribute
Visual Basic: 
  Sub Page_Load()
      btnSubmit.Attributes.Add("onClick", "return submitToFrame('page.aspx');")
  End Sub

clicking the button would cause this error in the target page
Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster.

i have several buttons which has different functions, and im doing most of the task on client-side since i intend to use this for transaction with lots of data so i cant rely on postback, except for my final submit

anyone? :confused:
 
This is because your changing the form values. This ASP.NET, not ASP 3.0. You do not change the target or the action in javascript and then post the form. You either post the form and leave all the form attributes alone (server side controls will detect their own changes) with javascript, let the form take care of it's own submission without messing with it in javascript, or do a window.location = in javavascript and use a query string (not recommended).
 
Based upon your other posts I HIGHLY recommend you getting Microsoft Press book "Programming ASP.NET" by Dino Esposito. You are obviously trying to do .NET as if it were ASP 3.0 and you will never succeed if you keep that mind set - they are day and night; forget everything you know about ASP 3.0 and VBScript - they will only stand in your way.
 
thanks bri189a for the answers as well as for the advice, i know im complicating things but the reason why im doing it like so is that i needed this single page not to reload itself (postback which it naturally does), which is a transaction page that has a lot of data written to it, so to make it faster (which is mainly the requirement) i needed it to do most part to client-side instead.
 
I work with some very high transaction applications and I've yet to find anything that I need to revert to ASP 3.0 type of posting. If you don't make the control a .NET server control then it won't post back.
 
bri189a said:
I work with some very high transaction applications and I've yet to find anything that I need to revert to ASP 3.0 type of posting.
Click to expand...

the need to do client-side arised when the list of product generated almost a 75-100KB HTML code (not a problem with broadband but dial-ups still exist) with the tables along with the data, since the transaction page requirement is to display every product categorized with its needed inputs (i would have done pagination if it wasnt for the requirement), not to mention having a lot of buttons with different functions (which will tend to postback on mouse click, thus, reloading the page over and over), the existing system actually does postback so often that youll notice it, and thats one of the clients main concern, we did suggest redoing the GUI so it would be rendered at less time and more userfriendly, but unfortunately they didnt want to keep it as is (i guess they didnt want to confuse the user, and also less training).

bri189a said:
If you don't make the control a .NET server control then it won't post back.
Click to expand...

do you mean something like using <input type="button" ... > instead of <asp:Button ...>, i tried doing that but it kept posting back (even the onClick's attribute in other objects), i guess ill give it another try.
 
Well there are a couple of solutions to this problem.

One use a AJAX to only update the things as they need it. This is the ideal solution but is more expesinsive to develop generally.

Two is to create you own controls that won't automatically post back or wire up your existing controls (with AutoPostBack set to false) to some javascript that hides/shows options that were intially downloaded but just weren't visible.

Sounds like your kind of boxed in by the customer though. Just document everything along with your suggestions and when they sign off on it and if they start complaining down the road you have your CYA material.
 
Back
Top