Category Archives: Development

Don’t Reuse SPQuery objects!

Posted on by
2

For God’s sake, don’t reuse SPQuery objects!

Now, with that out of the way, let me explain. I’ve inherited some code. In that code, it’s performing a couple of queries on a List, using an SPQuery object. It’s querying a boolean column, and only one item in the list should be true. It’s a long story why, but that’s the way it is. The list is something like this:

The code needs to query this list for true items (which should only be one) and false items (which you can see above, is more than one). However, these queries didn’t seem to be working. Continue reading →

How DisableEventFiring / EventFiringEnabled works

Posted on by
3

I’ve got an event handler on a SharePoint list that’s fairly long running, and this then raised a question in the office – do these settings control event firing for the currently running event handler, or for the entire list?

Very often you see lines of code like this…

this.EventFiringEnabled = false;
item.Update();
this.EventFiringEnabled = true;

… but was this really necessary? Are people worried about events not being handled ‘cos firing is disabled, or is this just a convenient way of tracking whether events are enabled or not? Continue reading →

Hidden fields, and controlling them with the Object Model

Posted on by
1

SharePoint’s fields can be ‘hidden’ or shown, by setting the SPField.Hidden property. That’s great, but sadly it isn’t that simple. You might want a field hidden, but allow administrators, etc., to ‘unhide’ the field. Then again, sometimes you might want your hidden field to be really hidden, and never ‘unhidden’.

That is actually what SharePoint allows. The SPField.Hidden property also relies on a second property ‘CanToggleHidden’. You can see this in the CAML definition of a field. So you could define a field like:

<Field Type="Text" ID="{449cf8bc-88ce-445a-ac55-11ea0cb71fed}" Hidden="TRUE" CanToggleHidden="TRUE" ... >

Okay, that’s fine – that’d give us a field which is hidden, but we can unhide. Note that by default CanToggleHidden is false, and this led to my problem. Continue reading →

Determine if a user is a farm administrator

Posted on by
Reply

Sometimes you just need to know if a user is a farm admin; conveniently SharePoint provides a couple of static methods on the SPFarm object to check this:

if( SPFarm.CurrentUserIsAdministrator() ) { ... }

Neat, but one tip – it’s not obvious but it seems that if you want to check this within a content web application, you have to use the method that accepts a boolean and that bool needs to be true:

if( SPFarm.CurrentUserIsAdministrator(true) ) { ... }

Otherwise you will only ever get a ‘false’ response.

Annoyance: GUIDs for Views must be upper case

Posted on by
1

So, I have a list where I’m using one of the views for my own nefarious purposes; I don’t want users to be able to see it normally, so I set it to hidden in my List Schema. That was fine, and worked.

However, I do need administrators to be able to edit that view – so I gave them a link that would take the to the ViewEdit.aspx page. This worked, except that whenever you tried to save any changes to the view, all you got was an error:

This seemed spurious – “View does not exist” - we’d just looked at the view, so how can it not exist? I tried unhiding the view, and testing, and I found that if I went by my link then I couldn’t save changes, but if I went by the standard UI, everything worked.

Great.

In the end I started comparing differences between the pages you got by my link and the UI. What I found was that some of the GUIDs in the page were, like my link, in lower case.

And that was the problem – the GUIDs in the URL needed to be upper case.

I surmise that someone is comparing strings during the ViewEdit save, rather than the GUIDs that they actually are. #FAIL.

HideCustomAction doesn’t work with the EditControlBlock

Posted on by
1

So, this is a new fact about SharePoint for me – HideCustomAction Feature element doesn’t work with the EditControlBlock. Normally, you add links to menus, toolbars, etc., using a ‘CustomAction‘, and hide them using ‘HideCustomAction’. Works a treat in most of the interface.

However, with the Edit Control Block (ECB) Hide custom action doesn’t work. It looks like ‘cos the menu is rendered by JavaScript, you can’t hide them. Liam Cleary posted a good article about it for SharePoint 2007, and I suspect this will be the same in 2010. It means you’re likely to have to use JavaScript to remove things off the menu :/

Don’t know how I managed to avoid this problem for 4 years!

Programmatically making a Field Required in SharePoint 2007

Posted on by
Reply

One of my colleagues asked an interesting question – programmatically, he’d just added a Site Column to a list, and now he wanted to make that column required on that list. The SPField class had a Required property, and on MSDN this is described as

Gets or sets a Boolean value that determines whether users must enter a value for the field on New and Edit forms.

However, this wasn’t what seemed to happen – although he’d set this to true and update the field, it didn’t make the field required.

He came and asked me why – and I didn’t really know. We knew that the radio button on the column settings did what we wanted …

… so we cracked open reflector to take a look. And this is what we found:

Yup, that’s right – if the field is on a list, the list uses content types, and “Advanced Management of Content Types” isn’t set, then the code gets the first (i.e. Default) content type, and sets the SPFieldLink that relates to that field to be required. Finally, it saves changes to the content type.

So, on a list that doesn’t use content types, to make a field required, you have to update the content type. Interesting…

Getting levels of the SharePoint Heirarchy and their Exceptions

Posted on by
Reply

Something that I have to do time and again is get some element of SharePoint’s heirarchy, such as a site collection, site, list or item. This is pretty typical – that’s why we all use USING to ensure proper disposal of SPSites and SPWebs, right? But what happens if the thing you’re after isn’t there? What exception get’s thrown?

Well, this should be pretty clear:

try
{
    //FileNotFoundException if doesn't exist
    using (SPSite site = new SPSite(siteGuid))
    {
        //FileNotFoundException if doesn't exist
        using (SPWeb web = site.OpenWeb(webGuid))
        {
            //SPException if doesn't exist
            SPList list = web.Lists[listGuid];

            //ArgumentException if doesn't exist
            SPListItem item = list.GetItemByUniqueId(itemGuid);
        }
    }
}
catch (System.IO.FileNotFoundException fileEx2)
{
    // Site or Site Collection Not Found
}
catch (SPException spEx2)
{
    // List not found
}
catch (ArgumentException argEx2)
{
    // Item not found
}

Hopefully that might prove useful to someone – and a good reminder for me.

Hide Column type from Lists

Posted on by
Reply

So, you’ve created a new custom Field (or column) type, but you don’t want it to be available to add directly to Lists and Libraries – that is, you want to force users to create columns as Site Columns, and add those to the list. Conversely, maybe you want to prevent a column being created as a Site column, and only available to add directly to lists (though I can’t thinik why).

Well, it turns out that that is possible. In the CAML defining your field in fldtypes_???.xml, you can have something like the following:

<FieldTypes>
    <FieldType>
        <Field Name="TypeName">MyCustomField</Field>
        <Field Name="ParentType">MultiChoice</Field>
        <Field Name="TypeDisplayName">My Custom Field</Field>
        <Field Name="ShowOnColumnTemplateCreate">TRUE</Field>
        <Field Name="ShowOnListCreate">FALSE</Field>
        <Field Name="ShowOnDocumentLibraryCreate">FALSE</Field>
        <Field Name="ShowOnSurveyCreate">FALSE</Field>       
        <Field Name="Sortable">FALSE</Field>
        <Field Name="Filterable">TRUE</Field>
        <Field Name="ShowInEditForm">FALSE</Field>
        <Field Name="UserCreatable">TRUE</Field>

ShowOnColumnTemplateCreate controls visibility as a Site Column type. The other ‘Show On X’ values control visibility as a List Column Type for different types of List. You could, therefore, have a Column Type that can only be used on, say, Document Libraries. Hope that helps.