Archive for SharePoint

While I’m here…….

Posted in InfoPath, SharePoint, Snippets with tags , , , , , , , on April 25, 2008 by Si

I remembered a couple of other little SharePoint snippets that I have found useful.

  1. Want to use that lovely green spinning icon that SharePoint uses when its doing something? Try the SPLongOperation class – good example here.
  2. Need to set the audience for a webpart through code? This is what I used!.
  3. Get the current user in InfoPath (not strictly SharePoint, but uses the SharePoint web services). Read this.
  4. Convert the XML that SharePoint returns into a dataset (I find myself using this all the time, probably because I don’t know better!):


public DataSet NSXmlToDataSet(string xmlString)
{
DataSet ds = new DataSet();
XmlDocument xd = new XmlDocument();

xd.LoadXml(xmlString);

XmlNamespaceManager nsMgr = new
XmlNamespaceManager(xd.NameTable);
nsMgr.AddNamespace("rs",
xd.DocumentElement.GetNamespaceOfPrefix("rs"));

XmlNode xn = xd.SelectSingleNode("//rs:data", nsMgr);

XmlNodeReader reader = new XmlNodeReader(xn);
ds.ReadXml(reader);

return ds;
}

Si

Advertisements

People in the field

Posted in SharePoint, Snippets with tags , , on April 25, 2008 by Si

SharePoint again folks! When dealing with users and groups (for example with list columns), SharePoint likes to store the underlying value in it’s own special format, usually ID;#Value (e.g “1;#neboddy”). That’s all well and good, but when you need to retrieve that value and display it in a friendly format (e.g. “Mr N E Boddy”) then there’s some work to do.

Fortunately SharePoint gives you a quick and easy way of getting at all the user properties for Mr Boddy (or anyone else for that matter!): SPFieldUserValue. Tada! Create a new object of that type, give it the value you’ve read from the list field, and then point an SPUser object at it, hey presto, you’ve got everything you could want. This saves having to write your own parser, and if Microsoft change the format down the line, they should update this class in the process.

Here is some lovely (delete if appropriate) code to demonstrate. This code was written to return either login names or email addresses for a multi-user field, hence the foreach() loop:


public string GetUserListFromField(SPWeb web,
                 string fieldValue,
                 bool returnEmail)
{
    string returnValue = "";

    //get collection of users from passed-in value
    SPFieldUserValueCollection allUsers = new
      SPFieldUserValueCollection(web, fieldValue);

    foreach(SPFieldUserValue fieldUser
               in allUsers)
    {
        //convert value to user
        SPUser user = fieldUser.User;

        if (returnEmail)
        {
            //return email address if requested
            returnValue += user.Email + ";";
        }
        else
        {
            //return login names
            returnValue += user.LoginName + ";";
        }
    }

    //trim the trailing semicolon
    int i = returnValue.LastIndexOf(";");
    returnValue = returnValue.Substring(0, i);

    //tidy up
    web.Dispose();

    return returnValue;
}

Copying documents between SharePoint libraries keeping version history (part 2)

Posted in SharePoint with tags , , , , on February 22, 2008 by Si

Quick update on my exploits so far in trying to keep document version history when copying documents between SharePoint libraries (i.e. what I wrote in the title!!)

Good progress has been made from the starting point I mentioned in part 1. I have had to make a few changes to deal with the fact my libraries have major and minor versioning, which started me exploring the properties and methods available in SharePoint’s object model. To explore this further, I knocked up a noddy application which would allow me to experiment without going through the faff of having to deploy and trawl through my K2 workflow all the time, and in that I found some useful stuff for handling versions:

SPFile.Level is an enumerated property which indicates whether a version is draft, published or just checked out.
SPFile.CheckOutStatus indicates the nature of the checkout (long or short term), and so can also be used to determine if a file is checked out.
SPFile.UIVersion gives the 32-bit integer version number, whereas SPFile.UIVersionLabel returns the ‘user-friendly’ version number (e.g. 1.0, 1.1 etc…). Properties are also available that return just the major or minor part of the label, if that’s all you need to work with. (Note: when working with SPFile.Versions, use SPFile.Versions.ID and SPFile.Versions.VersionLabel respectively.)

So at this point it is easy to handle the different versions as necessary. The next hurdle is, well, an odd shaped one and I will hopefully find a reason and solution for it in due course. For some reason, I am having issues with handling the new Office 2007 format files. For example, versions of an old .doc (Office 2003) format file is fine, but a new .docx (2007) format file throws an error. I haven’t got the exact message to hand, but will grab it and post it later in case someone can tell me where I am going wrong! So for the moment, I have ignored this one, as most people who use this system are using Office 2003 so it will not be a great issue.

And so I will wrap up this post with a quick mention of checking in and out documents as part of the process. In dink’s example in part 1, the versions just get published, but as I said I need to handle minor and major versions. There is a minor check you need to do to see if the document is new in the destination library (my code copies new versions over existing documents as well!), and if it is, then you don’t need to check out first, you can just save. I should also point out that my libraries both have minor and major versioning, and require check in/out. Checking out is quite simple, just use SPFile.CheckOut(), and checking in is equally simple with the SPFile.CheckIn(String, SPCheckInType). SPCheckInType allows you to specify whether it is a minor or a major version.

This post is quite long enough already, so in part 3 I shall pop up some code (I can’t put it all up as it is technically proprietary, but then again this stuff isn’t rocket science!).

Si

Copying documents between SharePoint libraries keeping version history (part 1)

Posted in SharePoint with tags , , , , on February 20, 2008 by Si

Currently working on a SharePoint project which has a requirement to copy and move documents from one library to another. No problem, I said. Keep the version history as well, they said. Fine, I said. And then I set about it, thinking everything would just happen automatically when you move documents.

Except it doesn’t. Moving, or copying documents from one library to another seems to cause SharePoint to lose any version history, so the document gets checked in at version 0.1 (or version 1.0 if you’ve only got major versioning set). So when I’d finally regained consciousness and come to terms with what I believe is a major flaw in the product (isn’t version history supposed to be a big part of its document management capabilities?!?!?!) I decided to park this particular issue and do something else……

Unfortunately it is a pressing requirement, so I have returned to try and find a solution. I feel I should point out at this stage that this is all part of a beautifully crafted K2 workflow solution, so I have to fit the solution in with that. And with some help from your friend and mine, Google, I quickly found I wasn’t the only person facing this problem. I found this post by ‘dink’ a useful starting point, and it gives some background on how SharePoint handles its versions.

http://www.sharepointblogs.com/dez/archive/2007/11/30/moving-copying-documents-between-libraries-with-metadata-including-version-history.aspx

I have started my solution based on the code example given, but need to tidy it up tomorrow, and will report back in due course. I think there are some optimisations to be made (such as handling the version number doesn’t need to be so protracted), but as I say I will post some of my code later.

Si