Custom control has 6 buttons in which 5 of them have CausesValidation = false, the one remaining button ( lets calls it as "SUBMIT") which cause validation.

Edit: Validators and Submit button are part of same validation group.

Coming to the Issue, when the form loads and I click "SUBMIT" button the validators work and error message is shown, but then I am unable to do any postback, all the buttons when clicked does nothing (no postback). This only happens when loaded in a webpart; it works fine in plain ASP.Net site.

Triage details:

  • Tested the "Page_ClientValidate()" , it shows properly (true / false) as per the validators, but still couldn't figure it out
  • Removed all the validators and added just one to narrow it down still same behavior
  • Tried putting break in firebug and test line by line, very tedious still working on it

Did anyone faced similar issue, any pointer should be fine.


  • Maybe the question is a little old, but can you please check if you were using some sort of UpdatePanel or anything similar? this behaviour remembers me of a "bug" related to the double postback protection logic used by SharePoint. Tell me if you need more detail (or if you just resolved the issue by switching to jquery validators).
    – SPArcheon
    Commented Oct 13, 2011 at 15:32
  • Sure, I need more information and would like to resolve it. I was time bound and couldn't spend much time on this. Please share your findings on this issue.
    – Vamsi
    Commented Oct 13, 2011 at 16:59
  • see my answer below.
    – SPArcheon
    Commented Oct 14, 2011 at 8:16

4 Answers 4


Don't know if your issue can be caused by this common problem (usually it's triggered by a partial postback), but I'm posting this anyway just in the case (and to help future readers that might stumble upon this page).

From what I have understand your first postback on the page works regulary but all the following ones seems to be "blocked" by some sort of page logic. You also said that the same page/control moved to a traditional ASP.NET context show no sign of the issue.

If that is the case, your postbacks might be blocked by the double postback protection mechanism built in in all SharePoint pages (similar to the form digest control). Basically when a page is submited, SharePoint sets a javascript variable called spFormOnSubmitCalled. If this variable is set to true, any additional postback will be silently cancelled... TheKid posted some metacode to better illustrate the issue (the post referes to SharePoint 2007, but the issue is almost the same for the 2010 version):

function _spFormOnSubmitWrapper()
   if (_spSuppressFormOnSubmitWrapper)
    return true; 

   if (_spFormOnSubmitCalled)
    return false;

This variable should be resetted when the page is reloaded - problem is that update panels, validator, third party controls and so on are know to cause issues where the variable is not reset. You can easly guess what will appen in that case: you page will get "stuck" and any sucessive postback will be simply ignored.

If you are hit by this problem you have three solutions:

  • set the variable :spSuppressFormOnSubmitWrapper to true. This will disable the protection logic - you should evaluate carefully if you can afford to do so. Anyway this is the easiest way to confirm that you are experiencing the issue - if after setting the variable the page start to work you can be reasonably sure that you have identified the problem.
  • try and change the page to avoid the problem. You can try to rearange your control and hope that the new layout doesn't trigger the issue (but I wouldn't hope too much). See this as a last resort.
  • try to patch the script that SharePoint uses. If you chose this solution try to redefine the script at the page level (overwrite the script in the page) - I know that it isn't exactly best pratices but your only other alternative would be to patch the file in the 14/ folder... and as you know Microsoft does not support any change to the OOTB files. If you select this solution this post could provide help - refer to the solution proposed by Laurent Cotton (user Suchii).

I had to implement the third solution in the past, but I am still not much confident of the other issue the "script fix" may trigger on other, uncustomized pages. Please use care - if your solution allows for it you might be safer to simply go for the first option.

Update: some months after the initial issue, I manage to have the customer rethink the page, so we restored the original, uncustomized version of the out-of-box SharePoint scripts. While we didn't detect any specific issues related to the workaround during that time, I would still advocate against it. Customization to SharePoint system files will put your whole farm in an unsupported status, so this should be a big no for most environments. If you really have to do this, please make the above clear to your customers.


Add proper validation groups to your Web Part - use the clientID as a part of the validation group name so it's unique within the page.

  • I did used validation group and I am sure its unique, the strangest part is that buttons with causesValidation=false are also not working
    – Vamsi
    Commented Sep 27, 2011 at 13:59
  • Hard to say without any code. [Shameless plug]I did write quite much about validators in the SharePoint 2010 Web Parts in Action book; manning.com/wilen [/Shameless plug] Commented Sep 27, 2011 at 16:22
  • Ok thanks, I will check that out. Will try to build a sample webpart and test the same scenario
    – Vamsi
    Commented Sep 27, 2011 at 19:48

Using JQuery for Validation . many more issues with validators


You havent mentioned which version you are using . For moss 2007 :

If it works well in asp.net i would suggest you build the same as usercontrol and host it in a smart webpart. Smart webparts allow you to host usercontrols in them without having to build and deploy sharepoint webparts .

You can get it here : http://smartpart.codeplex.com/

And to help get you started : http://weblogs.asp.net/jan/archive/2004/06/10/152932.aspx

  • This has nothing to do with custom validators, right. Validators is an ASP.NET thingie. Commented Sep 27, 2011 at 8:37
  • Yup , but as it was mentioned that it works well in asp.NET site , i have found the best way to work around these problems is by using smartpart .speeds up development in sharepoint for us dot net developers :)
    – Aabid Ali
    Commented Sep 27, 2011 at 8:48
  • I am using SharePoint 2010 with asp.net 3.5, smart parts are for exisiting asp.net application to be hosted in SharePoint with least efforts. When building from scratch we should avoid smart parts.
    – Vamsi
    Commented Sep 27, 2011 at 13:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.