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.
