Getting the "name" of an indexed item

[DJX]

I think this is a generic C# question:

In my program, I have an object that is a Sharepoint list item:

SPListItem item;

SPListItem is a collection containing the fields of Sharepoint item, and I
can reference the fields as:

item[int index];
item[GUID id];
item[string fieldName]

So I could use item[3] or I could use item["MyField"].

Question: How can I determine the "fieldName" (string) index value for a
given integer index.

For example, I'm looking to get the string value index associated with
item[3] (or item[4] or item[5], etc.).

 

[pedrito]

I think this is a generic C# question:

In my program, I have an object that is a Sharepoint list item:

SPListItem item;

SPListItem is a collection containing the fields of Sharepoint item, and I
can reference the fields as:

item[int index];
item[GUID id];
item[string fieldName]

So I could use item[3] or I could use item["MyField"].

Question: How can I determine the "fieldName" (string) index value for a
given integer index.

For example, I'm looking to get the string value index associated with
item[3] (or item[4] or item[5], etc.).

SPListItem provides the "Fields" property which I would suspect is in the
same order, but may not be. THe problem is the item[int] indexer vs.
item[string] indexer vs item[GUID] is an internal implementation of the
class and unless the class provides a mapping between them, there's no real
way to do it. It's not really a "generic" issue because it really does come
down to the individual class implementation.

If you think about it, in C#, you can implement an indexer in any class
with:

public object this[int]
{
get
set
}

in which you implement your getter and setter for the indexer. You might
provide an overload of the indexer that takes a string. But unless you
specifically provide some functionality publicly to map between the two
overloads, the user won't have any way of mapping between them.

Does that make sense?

 

[Peter Duniho]

I think this is a generic C# question:

I don't.

In my program, I have an object that is a Sharepoint list item:

SPListItem item;

SPListItem is a collection containing the fields of Sharepoint item, and I
can reference the fields as:

SPListItem is a single item in the list. The collection type is
(presumably) SPListItemCollection.

item[int index];
item[GUID id];
item[string fieldName]

So I could use item[3] or I could use item["MyField"].

The docs are not clear on this, but yes...I believe you. (MSDN's
reference for the SPListItemCollection.Item property suggests that only
an Int32 or Guid are suitable indices, but elsewhere they do discuss the
use of a field's name).

Question: How can I determine the "fieldName" (string) index value for a
given integer index.

For example, I'm looking to get the string value index associated with
item[3] (or item[4] or item[5], etc.).

Well, that depends. The docs also say that if you look something up by
name, the SPListItemCollection.Item property first checks for the named
item according to the internal name (the SPListItem.Name property) and
then by the display name (the SPListItem.DisplayName property).

So there's not actually a one-to-one relationship between an item's
integer index and its name.

That said, as long as you're aware of this limitation, it seems to me
that the answer to this question is that you can look at the Name or
DisplayName property, as appropriate.

So:

SPListItemCollection items = ...;
string strFieldName = items[3].Name;

Or:

string strFieldName = items[3].DisplayName;

That value should correspond to a string that you could use as the index
for the SPListItemCollection.Item property.

Pete

 

[Steven Cheng[MSFT]]

Hi DJX,

I agree with Peter that for different custom collection class, though it
may provide multiple indexer accessors, their implementation are not
guaranteed to be related or 1:1 mapping. And for the items in SPListItem,
the int32 and string indexer are not simply 1:1 mapped. Actually, both of
them are always located through a SPField value in its internal
implementation.

I have had a look into the code of SPListItem class via reflector.
Unfortunately, the code is obfuscated, but we can still get some code logic
from it. If you have interests, you can also have look, the following three
classes are the ones involved in the Item[...] indexer:
SPFieldCollection

SPListItem

SPListItemCollection
<<<<<<<<

Also, there is the general code logic of the two Item[] indexers of
SPListItem

=====SPListItem+Item[string]====


**call a method to find the SpField through the string(from a internal
private SPField Array)

**and locate the Item(object) through the SPField(a method accept a SPField
and interger value as parameters)


=====SPListItem+Item[int32]======
Item[int32]

**call a method which search the internal SpListItemCollectiop(private
member) and locate the certain SPField by the in32 parameter

**locate the item(object) through the SPField(the same method as in
Item[string] approach)
======================================

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.