Archive for July, 2009

Enable AJAX history in SharePoint Webpart pages

July 17, 2009

The problem:
You want to enable the back button in browser for the actions that are done through Ajax calls. It is pretty simple in a normal .NET 3.5 aspx web app. You can find the quidance here.

However this guidance did not work for me in a SharePoint webpart page. The history points in the back button browser history worked fine, the problem occured when I actually clicked the back button. The page changed back to the previous page  and then came back to the original page. After some fiddling I found out that this is because the __eventtarget parameter in the history page request is wrong. The parameter was set on the button and not on the scriptmanager as it should be. Therefore the button event click was fired when the history page wass loaded and then the original page was loaded again

The solution:
Create a new custom web part page. See Ted Pattison guide how to create a custom web part page. When done modify it and add a ScriptManager directly into the aspx code of the web part page. From now the browser history should work correctly.

When I used the Publishing page I did not come across this problem. Why? Did not have time to find out. 🙂

This feels rather like a workaround, if anybody ever reads this blog and has a better solution please let me know.

The SessionId is different with every request.

July 17, 2009

This problem can because nothing was written into the session and therefore the session is forgotten with the end of the request.
What you can actually do is to save something into the session during the request and everyting should work fine.
For example:
this.Page.Session[“dummy”] = DateTime.Now;
There are also some other good recommendations and gotchas here:

RunWithElevatedPrivileges behavior in different hosts

July 3, 2009
  Normal code RunWithElevatedPrivileges
w3wp.exe account of the currently loggedin user to sharepoint account under which runs the “sharepoint web application” application pool
owstimer.exe account under which runs the owstimer.exe service default it is NETWORK SERVICE account under which runs the owstimer.exe service default it is NETWORK SERVICE

As you can see runwithelevatedprivileges in owstimer.exe has no effect.

Custom membership provider:

Under which account runs the request when you use custom membership provider and there is no windows account associated with the user logged in to sharepoint? From my observations it is “Internet Guest Account”.

owstimer must be restarted after solution deployment

July 2, 2009