BeforeProperties and AfterProperties

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.

Advertisements
BeforeProperties and AfterProperties

TFS, Versioning and Office 365 SharePoint

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”

TFS, Versioning and Office 365 SharePoint

Don't Reuse SPQuery objects!

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!”

Don't Reuse SPQuery objects!

How DisableEventFiring / EventFiringEnabled works

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”

How DisableEventFiring / EventFiringEnabled works

Hidden fields, and controlling them with the Object Model

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”

Hidden fields, and controlling them with the Object Model

Determine if a user is a farm administrator

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.

Determine if a user is a farm administrator

Annoyance: GUIDs for Views must be upper case

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.

Annoyance: GUIDs for Views must be upper case