Invalid postback or callback argument

I keep logging several errors listed below. I have atlas running on my site with update panels on several pages. This error seems to occur if the user uses the browser "Back" button. Is there a way to handle or prevent this error?

Error on Page: /NewestMembers.aspx Error Date/Time: Aug 29, 2006 - 6:57:37 AM Error Message: Invalid postback or callback argument. Event validation is enabled using in configuration or in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation. Error Source: System.Web Session Variables: Query String Variables: Form Variables: __EVENTTARGET = ctl00$_MainContentPlaceHolder$_NewestMembersGridView __VIEWSTATE = DaDFsO2NFD857Ljt9WUlOwYfv+oo0/61zUbGTG2Pkk8FIBizVt4HTYQ1AvJn8Bqu9KvyOIuFoCAoM5QsFX+nUDo8XmvDj/HOprB05RLa9X8rH/cjzyL7GSv4QZMvnv0iRXzHoNVQzcdw3qn2tpI5qkx2WrcluAXJlUsfP9ZM501utfS1nlCJs5vxuODjD+iqRdCVHnMBVjcgbTJEHwP75iY7r8fV8QF0HKh8gBfUoC0rXS9x+XGgSlhOAMaUKcsZgcL04fDb7aE2a902NtdpOWXt4lmHk8l9mo78N6ew7nPnNlNByOAgIA99DoRBm5R8tH1fDrGgbV0QEpchSFzqmtcawjjoLfXnWTy5TWpv3wKzo6AvtNoWgosPpMPPCyWjN39nk75dR2FvKMl7u47OAssOPDaszIrEOS2COS5k6Pd3cgdhC3b2fWdZxwmanhS3HO8X1tSgPR53IsqlRHkEW/nkBdDK6PY+CVOhJqrNJNIZFV1Z6EaBniOyMMWvmdXBwSqP/hFxsRj99+yQ19AhcKAXYpJu2pyMVabfdKwkzeBbc2HtDTNlg54CBzEifERQTIz1B7m5R2Z6Bx2yk2DXZARFtiY9s4DRAbsVhZ+WvIC+wNINMFHYuCpFi/s7lx9iXj4paOv1+zBzp6TS3UknDcuKPxIoD1wdR3AeeDuLO5wP/dUomeDCBkltFIlk+vdmUxdWvRh/MSGC6028sjhnkLIXJkqoz8Hhs5hP+RitmAlYLxhFMVEix3JxooIH7z6wIomgr0GxNZGUtmQ6jsImwQF2IR3dXGOMmni0bTa0PE2SOpw+Vmv6l+Efw+1GLpZRMNdhHNs3Gl+m52TAySeeKf+1qr7voaXex0cXtLT0NHqhcU7kXi3xXt9guR4ZlHHfAJFdUF5NjoK23xHLPnpIfgPxE8Ff6GnvccQD+EBgVZMhKmVbOrRu4QsBrLkfjxHxkf1kKFOjU4fN9Md0IYhdrkjmSLxtIJPOLQLpwqeDaBa+t7cbdm56kB6VgN49++D6sbOVAefETFo52+dtnxm60bnHKPMrKQY+2fM2dVnQRJZolbGpK7nnyh/ymUqt+YpxGt2x7tIErxKeqsfUP/cOzfYgxmY6b6DFwKqmTT7XKBulm9AbPTIBp4nody3gN93259b4c0QLu4WQjAUKCplZKbsWQ1Y8lBPpuII/swZxWDmoXPY2FDnuOaDN8EajCMiPxwJYzJQC4yWaP7sfF4dYo8lGcnDctJrV0D9YawSX4jhYRQJmKBK+alYgZaodA3XrZY+0km2f9v+RBwZpGiIAwSXGoP9sRM3bXLR6esUcg/jjObWOgAWlRXg0V1pa5DRwVdFtg44c4dIPPNidSP0cqOZS92KxJ1Ghp9567VA53zbstlgwfNgQaC2g1cqhHm51E7mhSrbIceEZ26jrM7+1uiMAHz3BjAbkkZnWfekEDmyntGw7CJeN1SPSnW6uQqlny/RAdEKUqlIhgUPsHJtXN7oX0wFqOXyCejftNdGdcJsnJCtIP6Kf1ZM71qcDSyVuQw/VGDmcBJm9FCB1PUb5+Ri9j0uqL4M6asclg8SFT1Rz2HRdxL3GyfdWtQP7AL1yXBLW1SrQqJwOFJK8W0aGc7j61KNPygz2GRvnWKdW6le3T73q+7AnE87KSKrXnoJNjtOJXxY3SZBErP83W4ZTL/oJQXO8RdtKLrRGJWHRvy+QdtSvT6NkP1IEuaFUKb+rz1Ket2pfDw7tbTz9rv4KPqwNhBAVPZr8n4C8OWiR9UGAfXefOfiKD4UeUJxHCdeB+wL40vlfytfVJgr4HXgmV1iZA0axp+vVZU3uO3AywsPadMbB0vbQEO6U/lYEUflNvXu15tOLGlKJMkUZPmCouvqfnLrdtlBBde545nmVlWhbEOKuAN5Mi18wI+H6H/feY5hZvxi5C+sOYvNHdP1EKW6D+NqWEww9Iu0cfvDmjN5/x+k7/kZlImlTnHm3pMBua+fiiOmCZRVm6uawn7bVReIIYA5F6o57KamwL0sAL5oPXDPE4soNjoC+vgKQ4IRzNZvrdmxXQdwsr5LkFJpu/iIfqyCQxuGBwEjvSnprYjWBikPhim5aXR32J5X6+Dn25adiNM0wSFPUZrnrLAmhYU25rmZqNriVrkB3SQjWI20dmUWP9yLcQdqQkTogKI1Nm/BgGsGC4mEkx4Zcp1GydtIeXgIhOUI8pTK49CiA4lSUmwpxJdu8en+m2LsgqID+lWCSnIa6mA2SnTihdI10Wg== __EVENTVALIDATION = 2YRA4zH2000xi7Lksp82pi1+tHABGzOHht7Et+u77Weu3g/BHP9mPNIn43W1htX8pl8A+lgBfwaLZ1wEqFInQUSD95SpvsF87mANctA9ZJk= __VIEWSTATEENCRYPTED = ctl00$_MainContentPlaceHolder$ScriptManager1 = ctl00$_MainContentPlaceHolder$_upNew __EVENTARGUMENT = Page$2 __PREVIOUSPAGE = zubEIIwaLs1mi-rZEVX2KuSBbYvdLRKqzF9n-nadHR81 Error Stack Trace: at System.Web.UI.ClientScriptManager.Valid ateEvent(String uniqueId, String argument) at System.Web.UI.Control.Valid ateEvent(String uniqueID, String eventArgument) at System.Web.UI.WebControls.GridView.RaisePostBackEvent(String eventArgument) at System.Web.UI.WebControls.GridView.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument) at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) at System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postD ata) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Hi,

I don't know your scenario but you could try to give a look tothis article by Joteke and see if it could be your case.

All of my pages are using the object datasource. I'm not doing any manual databinding.

Any other ideas out there?

Thanks for your suggestion

I have the same problem.

Here is my scenario. I have an update panel along with an AutoCompleteExtender. I have a DropDownList with an autopost back to make changes to the ContextKey property of the AutoCompleteExtender on SelectedIndexChange. which is causing me to get the post back error.

Any fixes for this?

Thanks,
Kam

Is ASP.NET AJAX UpdatePanels are dangerous ?

Hi,

I am a big fan of using 'Update Panels'. Not because of the only simplicity but also bcoz of my belief on the AJAX framework.
But, at the same time lots of architects do say that, PageMethods [http://metasapiens.com/PageMethods/Tutorial/VS2005/] are more efficient than Update Panels.
Here is the link - ASP.NET AJAX UpdatePanels are dangerous.

http://encosia.com/2007/07/11/why-aspnet-ajax-updatepanels-are-dangerous/

After reading the page, I am quite suspicious on Update Panel and now think that really PageMethods saves perfomance overhead.But at the same time, simply by going thru few pages, accepting the same seems to be quite impractical.

Please let me know, is really PageMethods are more efficient than UpdatePanel. If yes, then please list me the things that cannot be done using PageMethods, which can be done by UpdatePanel.

Regards,

Arun

Hi,

dangerous is itself dangerous word in this context, but truth is that UpdatePanels, by design and due to their nature, pass a lot more stuff over the wire than PageMethods. Remember, they pass the changed markup, ViewState etc over the wire.

What the article/post says about it is true. However, it is always context dependant, is it an issue. Is the Page so big that async postback with UpdatePanel is unbearable? There are also ways to optimize things like reducing the unneeded ViewState, using multiple UpdatePanels to split the page to as-small-as-possible regions which need to be updated using UpdatePanel. E.g update only the parts which really need to be updated instead of passing everything you have on the Page. Using one UpdatePanel for entire page for example is not wise, if the page can be split up.

joteke:

using multiple UpdatePanels to split the page to as-small-as-possible regions which need to be updated using UpdatePanel. E.g update only the parts which really need to be updated instead of passing everything you have on the Page. Using one UpdatePanel for entire page for example is not wise, if the page can be split up.

I think it's important to keep in mind that even if you do break the page into multiple UpdatePanels, the entire ViewState is still sent to the server. On top of that, the Page and every single control in its control tree is reinstantiated, even if you're only visibly updating a tiny portion of the page.

The overhead associated with this can be relatively massive.

It would be nice to see if UpdatePanel could evolve so that its child controls would have viewstate field of their own (one per Panel), however that brings a lot complexity to the picture (especially from MS perspective) but also for developer to be explicit which Panels access each others child controls (that's why page now loads entire state because it must assume any control could be accessed).

While I'd use PageMethods too mostly today, I also like easiness of UpdatePanels and look for its evolution in vNext (meaning the one after Orcas/2008)

hello.

well, lets be honest: the updatepanel is a beautiful piece of engineering. having said that, i think that ajax is mostly done on the client, so major js,css, xml, etc is required. I'm not sure if changing viewstate is the way to go here. i'm thinking that what should be changed is the way we, developers, face our projects...

Is it a problem for Accordion Contents to Dynamically Change upon postbacks

I want to ensure that what I am trying to do is possible with an accordion control. I want to dynamically change the contents of panels during the life of a page in response to a postbacks. Do all of the controls have to exist upon initial creation in the page load? I am getting view state errors from time to time and don't know the cause. I have tried creating a large number of controls initially and then just making visible the ones that I want to display and making invisible the ones I want to stop displaying upon the postback. I also move the objects around within the html and within htmltables. Should what I am describing here work?

Follow-up to my own post: I've concluded that it is NOT OK to move the dynamically created controls around on an accordian panel during a postback. So what I am doing as a solution is to create all possible controls needed in advance and then making the ones needed be visible=true and not needed be visible=false. This seems to work from initial testing. Feel free to comment on this, thanks, but this is probably resolved.

Is it necessary to run the Asp.Net Ajax Installation Wizard

I have an issue where my web project works well locally with AJAX, Update Panels and Partial Rendering. Everything is kosher.

As soon as I copy my project to a staging server, any page that uses Validators that become enabled through Partial Rendering seem to have issues. The validators cause script errors on some pages, while on others, they are not visible.

The only difference between my local environment (that I can think of) that may affect this is that I ran the AJAX installation on my local workstation while on the Test Server I just copied the Ajax DLLs into the bin folder.

So does anyone know this may be my problem? Is it necessary to run the full install of ASP.Net AJAX for everything to work well? If not then I may need to resort to custom Javascript for client validation which I'd rather avoid since I can't run the install on the server.

no, but you will need to include the AJAX DLLs in your BIN folder then.

Thanks for your reply! It's good that all I need are the dll's since that's all I have access to do. But that now raises the question of why is it all good locally and not remotely on my test server.

Oh well.. I guess I have 2 options:
(1) Javascript for validation
(2) No partial-rendering.. postbacks and use FakeAjax transitions to make nice ajax-like UI.

alcsharp:

Thanks for your reply! It's good that all I need are the dll's since that's all I have access to do. But that now raises the question of why is it all good locally and not remotely on my test server.

Locally the Ajax DLLs are in the GAC, since you used the Installation Wizard. On the server they aren't there, so you need to explicitly include them.

Oh, and I'm betting you are missing a DLL...
What did you include?

I only included System.Web.Extensions.dll. Since I'm not using the Control Toolkit at all I didn't add it.