Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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.

Thanks

share|improve this question
    
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). –  SPArchaeologist Oct 13 '11 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 Oct 13 '11 at 16:59
    
see my answer below. –  SPArchaeologist Oct 14 '11 at 8:16

4 Answers 4

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.

share|improve this answer
    
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 Sep 27 '11 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] –  Wictor Wilen MCA MCM MVP Sep 27 '11 at 16:22
    
Ok thanks, I will check that out. Will try to build a sample webpart and test the same scenario –  Vamsi Sep 27 '11 at 19:48
up vote 0 down vote accepted

Using JQuery for Validation . many more issues with validators

share|improve this answer

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.

share|improve this answer

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

share|improve this answer
    
This has nothing to do with custom validators, right. Validators is an ASP.NET thingie. –  Wictor Wilen MCA MCM MVP Sep 27 '11 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 Sep 27 '11 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 Sep 27 '11 at 13:57

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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