This is super annoying.

It's pretty lame that the sample page at

http://ajax.asp.net/ajaxtoolkit/CascadingDropDown/CascadingDropDown.aspx

has EnableEventValidation=false for the page.

The fact that the CascadingDropDown extender breaks event validation should definitely by called out as a known issue on the sample page, rather than just sweeping it under the covers.

Ok I've mulled this over a little bit more; I see two possible workarounds, neither of which is particularly attractive:

• In the control or page that hosts the DropDownList and CascadingDropDown, explicitly make calls to ClientScriptManager.RegisterForEventValidation for every possible value that the drop down might be populated with by the CascadingDropDown web service. For large data sets, this might be prohibitively slow due to the time taken to calculate this set, or prohibitively expensive due to the resulting bloat of the __EVENTVALIDATION hidden field. In my case I was dealing with a small data set so this is the approach I took.
  
• Subclass DropDownList and override LoadPostData such that the Control.ValidateEvent method is not invoked. This sucks because it would involve copying/pasting source code decompiled via Reflector to make sure all other behavior is maintained. After writing this subclass, you would use this new class in conjunction with CascadingDropDown instead of DropDownList. At least this way you dont have to turn off event validation at the page level (and god help you if you use CascadingDropDown in a master page). I didnt write this sublclass myself, but I think this approach would work.
  

I'm curious. Has anyone come up with a workaround for this yet?

My drop down controls (the targets for the CascadingDropDown extenders) all have EnableViewState set to false (since the values are not needed back on the server, only the client javascript uses them). Still, I get the "Invalid Postback" error. Might it have something to do with the hidden input fields that keep showing up below the DropDowns in the DOM, after some drop down values have been selected?

Is there a way to turn off Event Validation for just certain controls? Do I need to somehow turn off the "Control Viewstate"? I doesn't seem to be there anyhow, so I think the problem might be the hidden fields generated by the extender.

As user jlewicki notes in an earlier comment, there does not seem to be an easy way to avoid setting EnableEventValidation for the scenario CascadingDropDown tries to enable. When the use of ClientScriptManager.RegisterForEventValidation is viable (e.g., with small, known set of drop-down data), its use seems like a good way to avoid having to disable EnableEventValidation as jlewicki indicates - but in general (e.g., calling into an external web service), it's not yet been clear to me how CascadingDropDown would be able to do any better automatically. jlewicki's proposal of subclassing DropDownList isn't something CascadingDropDown can do - though CascadingDropDown should be able to turn off EnableEventValidation during Page_Init without user intervention (http://msdn2.microsoft.com/en-us/library/system.web.ui.page.enableeventvalidation.aspx (http://msdn2.microsoft.com/en-us/library/system.web.ui.page.enableeventvalidation.aspx) ). HOWEVER, EnableEventValidation is a security setting and I would much prefer that disabling it (when necessary) be an explicit action by the web site author that leaves the page clearly modified so that nobody is surprised that EnableEventValidation is disabled for the relevant page(s). Accordingly, I'm closing this work item until/unless a suitable technique is found. (User Noffie is encouraged to post his/her possibly related issue to the forums and then open a new work item for that issue if necessary.)

I think the solution is to derive from System.Web.UI.WebControls.DropDownList, and do nothing else...

Explanation:
LoadPostData calls, ' base.ValidateEvent(postDataKey, values[0]);'

this in turn calls 'this.SupportsEventValidation'

which calls

SupportsEventValidationAttribute.SupportsEventValidation(base.GetType());

i.e. is based on the type of the control.
Looking into SupportsEventValidation
we find:
'object[] customAttributes = type.GetCustomAttributes(typeof(SupportsEventValidationAttribute), false);'

i.e. looks at an Attribute called SupportsEventValidationAttribute.

so unless the derived class is marked with
[System.Web.UI.SupportsEventValidation]
the validation is not performed, and
'
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.
'
does not occur.

In Short:

[System.Web.UI.SupportsEventValidation]
public class DropDownListX : DropDownList {
}

will fail,

public class DropDownListX : DropDownList {
}

does works...

I always believed deriving from a class and not adding/overiding anything would leave me with a class with the same behaviour as the base,
I stand corrected.

custom dropdownlist should be added along with extender

Why is this closed? The error still happens in 30930