“This page requires a plugin that can only run in 32-bit mode. Restart in 32-bit mode.”

On every. Single. Page. I learned to live with it for a while, but it became really annoying when it would shift the elements on the page a few seconds after load time, sometimes causing me to click the wrong thing. I came up empty handed after searching the internets so I set out into the world of Firefox’s about:config to find a solution.

Here’s how to fix the problem:

Type about:config in your address bar in Firefox. If it’s your first time in here you’ll get a warning to let you know that you could break things. Understand the risks and continue. Next you’re going to want to search this long list of settings for “x86″ and find “dom.ipc.plugins.enabled.x86_64″. Double click this setting to flip the boolean value from “true” to “false”. Now restart your browser and you should no longer see that warning when browsing a SharePoint 2010 site.

I have not noticed anything not working as a result of this change but I’d like to hear if you come across any problems.

Update: I did discover some problems with Flash not being properly displayed on other sites. Since changing the flag described above in the about:config settings and restarting your browser is not something you’ll want to do frequently, check out this post on how to run multiple instances of Firefox: https://devongovett.wordpress.com/2009/04/14/multiple-firefox-mac/

I now have two instances running, one with the x86_64 flag set to true (for general web use) and one with x86_64 flag set to false (for SharePoint 2010).

SPDisposeCheck is an incredibly useful tool which will analyze your custom SharePoint assemblies (compiled dll files) for memory leaks in the form of poorly handled SPWeb objects (very common issue!). Some of my company’s externally developed SharePoint applications were causing server wide SharePoint issues (memory leaks, poor server performance) which sparked the investigation. I was able to find most of the memory leaks just browsing through their code but SPDisposeCheck did it in seconds versus manually searching through thousands of lines of code and even flagged some bad coding practices that I did not spot. It does not fix the code for you but it does tell you the exact file, method, line of code and bad pattern detected so you can easily fix it. Most cases can be resolved with a simple using statement around SPWeb objects so that they are automatically released at the end of the code block but there are three options for disposing:

1. Wrap the new SPWeb object (“SPWeb web = new SPWeb(SPSite.OpenWeb())”) in a using statement
2. Use a try, catch, finally and call SPWeb.Dispose() in the finally block
3. Explicitly call SPWeb.Dispose() every time you’re finished with the object

Option #1 is usually my choice, but each have their use cases.

Note: You do need to use caution when disposing of objects that are called using SPContext (versus “newing up” a SPWeb object… “SPWeb web = new SPWeb()”) because objects created from SPContext are actually managed by SharePoint very well and if you dispose of it, the server will freak out when it tries to dispose of it. You won’t get memory leaks but your users will get nasty errors like Exception occurred. (Exception from HRESULT: 0×80020009 (DISP_E_EXCEPTION)) if not handled properly.

There is a great blog post that analyzes the patterns and shows how to prevent the memory leak in each case.

A great idea would be to configure SPDisposeCheck to automatically run as part of your Visual Studio build process and/or prior to being checked in to a code repository.

This is something that should be kept in mind when working with third party SharePoint developers and when developing solutions in house. It’s easy to miss these bugs but they can cause some serious problems for your SharePoint environment. Nothing should be deployed to production server until SPDisposeCheck returns a happy report on your custom assemblies.

What we want to do is to go from displaying our column data like this

to this

The key is to rely on the ddwrt XSLT extensions and wrap your selected element with the AutoNewLine function: “ddwrt:AutoNewLine (string(yourelementhere))”. Make sure you typecast it as a string or else you will get nasty xslt transform errors.

The resulting XSLT would look something like this:

<xsl:value-of select="ddwrt:AutoNewLine(string(@_x007b_70e17bba_x002d_be48_x002d_4f3f_x002d_ac0c_x002d_ebe359bebf49_x007d_))" disable-output-escaping="yes" />

MS has a summary of the ddwrt properties available here. Although the article refers to SPS 2003, the properties seem to hold true for WSS 2007 data views as well.

I hope this helps someone out there because there are not many clear references to this on the web that I could find!

02/13/2009 09:08:47.20     w3wp.exe (0x1158)                           0x1008    Forms Server                      Forms Services Runtime            82fp    Warning     Exception occurred during request processing. (User: server\dev, Form Name: , IP: , Request: http://server/_layouts/FormViewNotify.aspx?XmlLocation=/sites/ff/Formulations/032034.xml, Form ID: , Type: XmlException, Exception Message: There is an unclosed literal string. Line 1, position 898.)

I couldn’t find any problems in the form code or the xml schema so I hit google and found a hotfix that microsoft released for this issue. The kb is 949752 and you can get it here: http://support.microsoft.com/kb/949752. It solved my issue and the forms render fine when views are changed.

Not sure really. Bug or undocumented feature? For some reason the form needs to be deactivated and then reactivated to your site collection in order for the fields to be properly promoted.

First, create a new data connection to receive data from a web service:

http://<yoursharepointserver>/_vti_bin/UserProfileService.asmx?WSDL

The operation you want in order to get the user’s full name is GetUserProfileByName

leave the account name parameter blank, we will populate it on the fly

uncheck ‘store a copy of the data’

then check the ‘automatically receive data when form is opened’ box and the web service is ready for use.

What I have done is created a new string data source (field) called ‘name’, you can call this anything you want. Set the default value of the field to be this formula (click the fx button) and make sure to remove any line breaks:

("GetUserProfileByName")/dfs:myFields/dfs:dataFields/
s0:GetUserProfileByNameResponse/s0:GetUserProfileByNameResult/
s0:PropertyData[s0:Name="PreferredName"]/s0:Values/
s0:ValueData/s0:Value

If you have problems pasting this in, make sure to turn on the “Edit XPath (advanced)” checkbox option on the Insert Formula window. You could replace “PreferredName” with “WorkEmail” or any other SharePoint profile property you want to retrieve.

Now you’re ready to display the user’s full name in your form or append it to a filename or anything else you can think of.