Office Server 2007 Ramblings : Bugs

Customising Search Results via XSLT

bsandeman — Thu, 17 Jan 2008 15:47:00 GMT

Recently I have been customising MOSS search results pages using XSLT and am quite pleased with the results ;-). However, one requirement from our customer was to break up the document url into it's component parts and provide links to site and library...(read more)

Date modified in Sharepoint lists

bsandeman — Tue, 09 Oct 2007 16:46:00 GMT

Well the underlying issue of my previous post was the fact that, when creating a calculated custom field referring to the system field "Modified" as part of the calculation in a document library, the value would change to 01/01/1899 when a document was...(read more)

Just to clarify

bsandeman — Wed, 24 Jan 2007 19:12:00 GMT

In my previous post I went by gut feel on timings, I have now been able to do some proper testing and timings using a demo form which are as follows.... Times to change view via C# code : 175 Rows - IE : 29 seconds FF : 9 seconds IP Client : 1 second...(read more)

Sharepoint ItemDeleting Event

bsandeman — Mon, 04 Dec 2006 17:34:00 GMT

I have recently started work on handling some of the events that can happen on a form library. One of these is the ItemDeleting event. This occurs during the delete process for an item. As the deletion of an object is part of a business process we had to copy the item to a Deleted library. This I did using properties.ListItem.File.CopyTo which worked fine until Thursday of last week when my VS solution went belly up and vapourised it's links to my ItemHandler project. Once I added my project back in this process never worked again. I have continued to receive the following error in sharepoint logs and the event viewer - "Cannot lock file "12.xml". Either the file is in use or the Web server is temporarily busy."

The only way I have managed to work around this is to do the following :

StreamReader r = new StreamReader(properties.ListItem.File.OpenBinaryStream());
String xml= r.ReadToEnd();
r.Dispose();

xmlDoc = new XmlDocument();
xmlDoc.LoadXml(xml);
namespaceManager = new XmlNamespaceManager(xmlDoc.NameTable);
namespaceManager.AddNamespace("ns1", appParams.get("xml_namespace"));

SPWeb web = properties.ListItem.Web;
SPFolder folder = web.GetFolder("/treasury/DeletedInvoices/");
SPFileCollection fileColl = folder.Files;
SPFile file = fileColl.Add(properties.ListItem.Name, 
                   Encoding.ASCII.GetBytes(xmlDoc.OuterXml));

This shows all my code which is actually split up nicely into functions, but hopefully this gives you the idea.

InfoPath 2007 RTM

bsandeman — Mon, 04 Dec 2006 17:11:00 GMT

Well it would seem that there is a little issue of compatibility between forms created under beta2 TR and the RTM release. This is fixable but requires a little bit of effort for the forms where this problem occurs, by no means will it be all forms....You will also only have the problem if you are creating a browser compatible form.
Now if you receive the error "The view contains nested formatting which is not supported on InfoPath Forms Services. Examples of such formatting include heavily nested tables and heavily formatted text." from either design checker or when you try to upload your form to Sharepoint then this means that you have the problem that I ran into.
Now the reason for this error seems to be that within the beta2 TR(possibly also in earlier incantations) there was a bug which meant that the XSL produced for 1 or more views in a form gets damaged so that you end up with horrendously nested html tags; in my case truckloads of <font> tags. This has been fixed in the RTM release and it would seem that Sharepoint now considers deeply nested tags to be a bad thing, as well it should. :-)

There is only one way to fix this and that is to do the following:
(use the RTM version for all of this; as that's what I did)
1. Save your InfoPath form as source files
2. Close your InfoPath form and browse to where you saved the source files
3. Open the xsl file that corresponds to the view with the problem (you will only know the correct view if you use the design checker first to locate the problematic view, be aware you may have more than 1 view with the problem, I had 2)
4. Scroll through the xsl and look for some horrendously nested (indented) tags. Now be careful, as you do not want to delete any tags that are within the nested tags, but you want to delete the nested tags.
eg: <font face="arial"><font face="arial"><font face="arial"><input type="button"></font></font></font>
in this example I only show 3 nests but expect more like 30 nests; to fix delete everything so that you have left <input type="button">
5. Save the xsl file
6. Right click manifest.xsf and choose design, this opens the form for design
7. Either you can continue working with the source files (my preference as I can store these in our source control system better than a binary file as I can report on the changes) or save it as a new XSN file

hope this helps those of you that run into a similar situation; thanks to Scott Heim at MS for telling me how to reuse the source files once I had edited them, I was trying to recompile them back into a cab to start with, doh!