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.
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
down to:
(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.
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.
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.
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.
bri189b
Member
163 Points
56 Posts
WebForm_DoPostBackWithOptions vs __doPostback
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.
Thanks,
Brian
bri189b
Member
163 Points
56 Posts
Re: WebForm_DoPostBackWithOptions vs __doPostback
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 down to:
(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.
bri189b
Member
163 Points
56 Posts
Re: WebForm_DoPostBackWithOptions vs __doPostback
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.
Please help.
bri189b
Member
163 Points
56 Posts
Re: WebForm_DoPostBackWithOptions vs __doPostback
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.
bri189b
Member
163 Points
56 Posts
Re: WebForm_DoPostBackWithOptions vs __doPostback
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.
Interesting indeed.
silverfox_11...
Member
50 Points
19 Posts
Re: WebForm_DoPostBackWithOptions vs __doPostback
Feb 28, 2007 06:37 PM|LINK
Hi,
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.
Thank You,
Jim
alexmanfree
Member
4 Points
4 Posts
Re: WebForm_DoPostBackWithOptions vs __doPostback
Aug 27, 2008 07:18 AM|LINK
Hi,
This article may be helpful for some ppl:
Preventing double form submit in ASP.NET (2.0)
http://www.abstraction.net/ViewArticle.aspx?articleID=80
akash3892
Member
2 Points
1 Post
Re: WebForm_DoPostBackWithOptions vs __doPostback
Dec 01, 2008 06:06 PM|LINK
Hi,
please try and setCausesValidation
=false for that particular linkbutton.This may help you.
Regards,
Akash