There's no way to get the ValidateRequest behavior any other way though. The
chekcing for this occurs inside of the guts of ASP.Net, so there's little
you can do about changing the behavior other than capturing the exception.
I'm not sure I see the problem though because if you use Page_Error() you
get notified immediately if the erorr occurs at which point you can call
another method that does the right thing. Isn't this pretty much what you're
asking? Remember the failure will be the first thing that happens. You can
simply ignore it and call Page_Load manually for example to go on (Actually
I think you may have to force the page to manually render at that point but
that's still pretty straight forward.).
+++ Rick ---
--
Rick Strahl
West Wind Technologies
http://www.west-wind.com/ http://www.west-wind.com/weblog/
----------------------------------
Making waves on the Web
"Jim Butler" <un**@companyabc.com> wrote in message
news:#D**************@TK2MSFTNGP09.phx.gbl...
We are using a custom guid generator with encryption, the problem is
sometimes pages will blow up when accessing this value through a post or
get. The encryption mechanism will sometimes generate the "bad"
characters to create this error. We would like to continue to leave validateRequest
turned on. What we would really like to be able to do is call the method
manually to catch an error before the user see's it and generate a new
guid for them that will pass when encrypted. I believe the method is private,
thus our dilema. Is there someway to get around this? Right now, we
generate the value, call a custom page to see if it fails, if so, then
generate a new value. This is way too much work....
Any help much appreciated,
jim butler