BeforeProperties and AfterProperties

2012-11-212014-11-30 Andy BurnsEvent Receivers, SP2007 Development, SP2010 Development, SPItemEventReceiverLeave a comment

I am sick of having to hunt down the link to Synergy’s post on the BeforeProperties and AfterProperties available in different events on SPListItems. For my reference, here it is:

List:

List	BeforeProperties	AfterProperties	properties.ListItem
ItemAdding	No value	New value	Null
ItemAdded	No value	New value	New value
ItemUpdating	No value	Changed value	Original value
ItemUpdated	No value	Changed value	Changed value
ItemDeleting	No value	No value	Original value
ItemDeleted	No value	No value	Null

Document Library:

Library	BeforeProperties	AfterProperties	properties.ListItem
ItemAdding	No value	No value	Null
ItemAdded	No value	No value	New value
ItemUpdating	Original value	Changed value	Original value
ItemUpdated	Original value	Changed value	Changed value
ItemDeleting	No value	No value	Original value
ItemDeleted	No value	No value	Null

Note: Allegedly, this does change if the event receiver is synchronous – the before properties are available. I’ve not checked this out yet.

Obviously, for SharePoint 2007 systems that doesn’t apply – as ‘*ed’ event receivers are always asynchronous.

TFS, Versioning and Office 365 SharePoint

2012-04-032014-11-30 Andy BurnsSandbox, SP2007 Development, TFSLeave a comment

So, I am a big fan of putting build numbers or SVN revisions into the AssemblyFileVersion of my assemblies. I can then use a little bit of the System.Reflection API to get the AssemblyFileVersion, and display it to the user, write it to logs, etc..

However, I ran into a hitch when working with Office 365. Although reflection worked fine on my local machine’s sandbox, I got an error when I tried to run the same code on Office 365’s SharePoint system. It was pretty obviously and emphatically using System.Reflection that was the problem.

This was a shame, as my build process is (as usual) putting the AssemblyFileVersion in. Sadly, I don’t see any easy way to get the AssemblyFileVersion value from within Office 365 code. So, alternatives? Continue reading “TFS, Versioning and Office 365 SharePoint” →

Don't Reuse SPQuery objects!

2011-06-022014-11-30 Andy BurnsSP2007 Development, SP2010 Development, SPQuery3 Comments

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 “Don't Reuse SPQuery objects!” →

How DisableEventFiring / EventFiringEnabled works

2011-01-052014-11-30 Andy BurnsEvent Receivers, Reflection, SP2007 Development, SP2010 Development, SPItemEventReceiver6 Comments

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 “How DisableEventFiring / EventFiringEnabled works” →

Hidden fields, and controlling them with the Object Model

2011-01-032014-11-30 Andy BurnsSP2007 Development, SP2010 Development, SPField5 Comments

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 “Hidden fields, and controlling them with the Object Model” →

Determine if a user is a farm administrator

2010-12-312014-11-30 Andy BurnsPermissions, SP2007 Development, SP2010 Development, SPFarm1 Comment

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

2010-12-232014-11-30 Andy BurnsSP2007 Development, SP2010 Development, SPView, Views1 Comment

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.

Random things I learnt doing a code review

2010-12-132014-11-30 Andy Burns.NET, SP2007 Development, SPListItemLeave a comment

Code Reviews are interesting – both sides can learn something, and the one I’ve just done taught me a few things… Continue reading “Random things I learnt doing a code review” →

HideCustomAction doesn't work with the EditControlBlock

2010-12-032014-11-30 Andy BurnsCustomAction, SP2007 Development1 Comment

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

2010-10-282014-11-30 Andy BurnsSP2007 Development, SPContentType, SPFieldLeave a comment

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…

Andy Burns' Blog

Whatever I'm working on

SP2007 Development