I’m not entirely sure what this means, but I found it curious…
I had a big block of unoptimized code in a project I’m working on and so I lost track of what variables I had and where they had come from. At one point, I created an SPListItem by retrieving it from an SPListItemCollection. So far, so good. Nothing unusual:
SPListItem itm = lic;
Later on, after checking that this item represented an SPFolder, I grabbed it’s corresponding folder object:
SPFolder myFolder = itm.Folder;
Later still, I had to grab a column value. Forgetting that I had the SPListItem directly, I went this route:
string myValue = (string)myFolder.Item[“myField”];
In stepping through my code, I found that myValue was null, when I knew that it did, in fact, have a value. Looking at my code to figure out what I could have f-ed up, I saw the itm variable again. I didn’t expect it would fix my problem, but it would be cleaner to work directly with it instead of going through the folder object, so I changed my code to:
string myValue = (string)itm[“myField”];
Now when stepping through my code, myValue wasn’t null, it threw an ArgumentException error. WTF?
So, in other words:
SPListItem != SPListItem.Folder.Item
even though both are SPListItems, and I would have assumed the same SPListItem (which they really are because both have the same ID, there’s just something screwy going on with the available fields).
This is mostly a note to myself to fire up Reflector and see what is going on when I have more time. I’ll try to remember to update this post if I can figure it out.
Imagine that…another head-scratcher from the SharePoint object model…
Last night at the final @TSSSPUG meeting of 2011, Michael Mukalian and I presented an informal couple of sessions covering various tips that we’ve learned over the years of beating our heads against the SharePoint wall. Here’s a quick review of what I covered…
Add the following lines to the top of your .js files to get intellisense for JQuery and the Client OM:
/// <reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\MicrosoftAjax.js" />
/// <reference path="c:\IntellisenseFiles\jQuery-1.7-vsdoc.js" />
/// <reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\SP.core.debug.js" />
/// <reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\SP.debug.js" />
Note that the path in the second entry is to a folder on my dev machine where I put the –vsdoc files downloaded from the JQuery website. Adjust your path as appropriate.
I did a quick overview of the DevDash and why it is useful.
There’s NO REASON not to use this tool. Just Do It. www.cksdev.com
O365 FxCop Rules
If you’re doing Office 365 development, this is another must-have tool: http://o365fxcoprules.codeplex.com/
Resolving Sandbox timeout errors
On a development box only, add the following entry to your HOSTS file to improve the responsiveness of your sandbox process when it is starting up: 127.0.0.1 crl.microsoft.com
Adding a "close" link to the Status Bar with your status messages
Using PowerShell in the VS Pre/Post Deployment steps
%windir%\sysnative\windowspowershell\v1.0\powershell -file "$(ProjectDir)MyPSScriptFile.ps1" where MyPSScriptFIle.ps1 contains your PoSh commands to be run
Using LinqPad as a snippet compiler/tester
LinqPad: (free) http://www.linqpad.net/
Hopefully folks got some value out of the session.