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[0];

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…