0

I have a general question around unboxing vs parsing of the identity property on an SPFieldLookupValue.

Let's say, we have a call to a list and we get a reference to the a lookup field:

// call to site / web, get instance of class and iterate through records
// find column [lookup field]
SPFieldLookupValue fieldName = item["ALookupField"] as SPFieldLookupValue;

In the example above, I have a reference to the lookup value, whereby I can pull the Id and the Value separately instead of working with a string (ie. id#value).

Now, the LookupId property is of type object, but I know that this value will in almost all cases be an integer, so my assumption here is that I can do:

int id = (int)fieldName.LookupId;

But, obviously I need to ensure that I am working with an integer, so I should, in theory, try and parse this to the type I need:

bool isInt = int.TryParse(fieldName, out intField);

I know that this is probably more accurate, but my question is why can I not explicitly unbox the object, to it's int equivalent, when I know that it will most likely always be an int?

1

LookupId is of type int. See here

| improve this answer | |
  • And he is casting to int? – Robert Lindgren Aug 27 '13 at 10:26
  • There is no need to cast as property itself returns int. He can simply use int lookupId = fieldName.LookupId – Nadeem Yousuf-AIS Aug 27 '13 at 10:39
  • As Nadeem said, LookupId property is already int. You don't need to explicitly cast it to int ! – Arsalan Adam Khatri Aug 27 '13 at 10:39
  • What I meant really, was the you maybee should extend your answer to make sure OP realized what you mean by that, and how he could go along without any casting :) – Robert Lindgren Aug 27 '13 at 13:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.