Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Dec 01, 2008 06:06 PM by akash3892
Nov 27, 2006 05:32 PM|LINK
What decides which of these will be rendered?
I have a web test that I can't get to pass because it always give me MAC viewstate validation error (or something to that effect) when it gets to a page with dynamically added link buttons and one of those is clicked...these are receiving the WebForm_DoPostBackWithOptions
client side script for posting back.
In a seperate project I have simulated a similiar scenerio but on this one the dynamically added buttons (using literally the same code) gets rendered with __doPostback. Obviously there is something different between the two, and it probably has to do
with something of the container controls, but if I knew what causes the new version of postback client script to render instead of the old __doPostback I think it could help me diagnose the problem.
I have searched Google and MSDN for some sort of definition of why one gets rendered instead of the other but haven't had any luck.
Nov 27, 2006 07:02 PM|LINK
Thank you Lutz:
Apparently the new version will always be used unless (PerformValidation == False && TrackFocus == False) && (ClientSubmit == true && ActionUrl != null && ActionUrl != string.Empty)
For LinkButton ClientSubmit will always be true, PerfomValidation will always be False, and TrackFocus will always be False because of the internal constructor that is used (when calling GetPostBackOptions in AddAttributesToRender), so it basically comes
(ActionUrl != null && ActionUrl != string.Empty) - basically if ActionUrl is set to something other than "" the new format will be used for a link button, otherwise the old __doPostBack will be.
What I'm finding interesting is that on this particular problem ActionUrl is not being set, so I need to investigate further. Hope this helps someone.
Nov 27, 2006 08:10 PM|LINK
There must be something else hidden deeper. For whatever reason, this link button is rendering with that new WebForm_DoPostBackWithOptions even though the ActionUrl isn't set. I can't figure out how it's being done, even looking through reflector, the
only different with this web application is that it's using the Web Application Project but that's it and I don't see why this would matter at all.
Nov 27, 2006 08:23 PM|LINK
Early I said:
PerfomValidation will always be False
This is not true, in GetPostBackOption, if causes validation is set to true, and there is something to validate, then it will change the PerfomValidation setting to True; this answers some of my questions, and interestingly enough there are 27 items in
the ValidationGroup, even though on that page there is no controls to validate, no validators on the page, and all 27 items are string.Empty, so more digging.
Nov 27, 2006 08:28 PM|LINK
So apparently if you have validators on a control that is currently invisible, it still gets added to the Page.Validators collection.
Feb 28, 2007 06:37 PM|LINK
I'm having the same problem as you did. Were you ever able to figure out why WebForm_DoPostBackWithOptions is used instead of __doPostback on some cases running asp.net.
Aug 27, 2008 07:18 AM|LINK
This article may be helpful for some ppl:
Preventing double form submit in ASP.NET (2.0)
Dec 01, 2008 06:06 PM|LINK
This may help you.