We have been on the quiet side on the blog lately, but fortunately that’s because we’ve been super busy with customer work. This means we need more dev muscle.
Sorry for spamming the blog with a recruitment plug, but if you are a guru dev looking for a change of scenery in the Vaasa region, have a look at our job posting on our main web site here. Thanks!
In a previous SharePoint project, I implemented a few event handlers that get called whenever an item in a list gets changed (or added/deleted). There were a few problems along the way that took a bit of searching before I found solutions. This post documents a few of the things that are good to know.
The event handlers that I implemented where all of the synchronous ItemUpdating kind. There are also asynchronous events, like for instance ItemUpdated, but for the scenario at hand, I wanted to have some special handling depending on certain values of an item.
The event handler is of the form
public override void ItemUpdating(SPItemEventProperties properties).
Here comes the first gotcha; the BeforeProperties are only populated for document libraries. If you have an event handler on a custom list, the BeforeProperties collection is empty. So in order to check the current value of a field, you have to use properties.ListItem[<field name>] instead.
Second gotcha; be aware of the internal name of fields. They have a sneaky behaviour in this case. As usual you should use the internal name of the field instead of the display name when accessing the field, i.e. “Evaluation_x0020_Date” instead of “Evaluation Date”. However, you can do properties.ListItem[“Evaluation Date”] to get the current value of the field, BUT to get the new value from AfterProperties, you have to do properties.AfterProperties[“Evaluation_x0020_Date”]. Here comes the even sneakier behaviour; if you try to do properties.AfterProperties[“Evaluation Date”], it doesn’t fail, but returns null. Usually, if you try to access a field that does not exist, an exception is thrown. However, “Evaluation Date” passes as a valid field name, but the value cannot be found.
The third problem I had was related to date fields. In my event handler, I wanted to make sure that a certain date field remained unchanged if some other condition was met. The easiest solution would of course be
properties.AfterProperties[“Decision Date”] = properties.BeforeProperties[“Decision Date”]
As already stated in the first gotcha, the BeforeProperties is not populated for lists, so the statement was revised to
properties.AfterProperties[“Decision Date”] = properties.ListItem[“Decision Date”]
Now, this is still too simple, if you read the gotcha number two, you know that we have to use the internal name. Taking this into account, the third revision of the line is
properties.AfterProperties[“Decision_x0020_Date”] = properties.ListItem[“Decision_x0020_Date”]
This still doesn’t work. Even though all the properties are strings, and it is the same field, the formats of the strings are somehow still incompatible. The data type in this case was a datetime. It turns out that the format that comes out of the ListItem is in the format the SharePoint site uses, while the AfterProperties need the date in ISO8601 format. The fourth and final iteration (that actually works) of the line ended up as
properties.AfterProperties[“Decision_x0020_Date”] = Microsoft.SharePoint.Utilities.SPUtility.CreateISO8601DateTimeFromSystemDateTime(DateTime.Parse(properties.ListItem[“Decision_x0020_Date”].ToString()))
Short and concise.
A couple of days after my last post about tools for WPF debugging, I got the word that Snoop has been made open source and released on Codeplex. There are versions for both 32- and 64-bit systems, and even WPF 4.0 is supported.
This version of Snoop is based on version 2 of the original Snoop and contains a merge of the improvements done by different people, so it supports on-the-fly editing of properties, WPF interop scenarios (WPF hosting Windows Forms or vice versa), bug fixes including support for visual trees with more that 255 levels, among other improvements. Check out Cory Plotts’ blog post about the release.
Just a short note about a couple of tools I've been using when developing WPF applications. Please refer to the links for more information about the tools.
Snoop provides visual debugging of WPF applications at runtime.
Crack.NET is a runtime debugging and scripting tool. Also supports Windows Forms applications.
Mole is a Visual Studio visualizer allowing unlimited drilling into objects and sub-objects.
Due to the way the hooks are written, neither Snoop nor Crack.NET will work on 64-bit processes. However, there is an x64 version of Snoop available on Dan’s IK Blog (there is an updated version here). This version is based on an earlier version of Snoop where property value editing is supported, so even though you’re living in a 32-bit world, you can take advantage of this version.
Check them out!
Microsoft Office Groove has a nifty little hotkey. If you press shift twice, a dialog comes up to let you write a message. This is even more annoying than the accessibility sticky keys or filter keys dialog. And guess what, there is no way to disable the hotkey in the user interface! I haven’t found the place to do it at least.
I got so annoyed with this that I asked our internal IT support how to disable it. The answer was that you have to edit the registry.
Here are the instructions I got. And remember, all the normal disclaimers apply: It is dangerous to modify the registry if you don’t know what you’re doing! We are not responsible for any damage that may occur if you try to follow these instructions. With that out of the way, here’s the information you have been waiting for.
Really simple, right?
When declaring a feature, you can add an <ActivationDependencies> section to your feature.xml file. Here you can list the features your own feature is depending on.
According to the documentation on activation dependencies (http://msdn.microsoft.com/en-us/library/aa543162.aspx), the depending features get automatically activated if they are in the same scope: “If a Feature is dependent on another Feature at the same scope, and the second Feature is not activated when the first one is activated, Windows SharePoint Services activates the second Feature”
This is incorrect!
The second feature is activated automatically only if it is hidden!
As the self-proclaimed alpha male of the nerd herd here at eCraft I also want to add my 2 cents to why we’re doing this blog and what we expect to do with it.
I think in short it could be described as us bringing all those interesting, weird and wonderful discussions that happen in the corridors of the eCraft offices out in the public, especially those discussions that relate to software development and technology. Like Jörgen wrote in his post, there will be code, there will be ideas, there will be thoughts and there may even be an application or a video or two. And rest assured, all of it will be somewhat half-baked. Because we’re not selling anything here, we’re just sharing things that we find interesting and that we discuss among ourselves with a wider audience. And we hope that there will at least be some amount of discusson and comments from that audience.
Because who knows, you just might find some of this stuff useful.
eCraft Labs is the home of the geeks at eCraft. It's a bit messy. Some stains, pizza boxes and coffee cups may be found laying about. As the name suggests, we will post experiments, thoughts, ideas, snippets of code, small utilities, real life experiences from the trenches, videos and so on. None of the posts have been tested on animals. We take pride in that.
We will try to be as meticulous as always, but since this is laboratory grade stuff, use it or ignore it at your own risk.
If you are looking for our business blog, please head on over to episto.la. If you are looking for our official site, www.ecraft.com is were you should go.
Now, enjoy and participate. We'd love to have your feedback.
