Michael Crawford wrote:
The following gdb console output demonstrates an instance of a
media-item persistent-ID property that, when queried gives a large
unsigned number. When I ask again using the -longLongValue method,
I get the answer I was expecting. When I look inside the set, you
will see that the value -1748299021286640132 is in the set.
However, when -containsObject is called, it returns NO.
If the persistent-ID is unsigned, then longLongValue seems like the
wrong type to use. There are NSNumber methods for working with
unsigned long long types. Try using those exclusively and see if it
changes anything.
NSNumber has a method that returns the type encoding as a C string (-
objCType). The long long type has a different value from the
unsigned long long type: "q" vs. "Q".
There's also this special consideration (see NSNumber class reference
doc):
"The returned type does not necessarily match the method the receiver
was created with."
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/
Foundation/Classes/NSNumber_Class/Reference/Reference.html%23//
apple_ref/occ/cl/NSNumber
The type encodings reference:
http://developer.apple.com/library/mac/#documentation/Cocoa/
Conceptual/ObjCRuntimeGuide/Articles/ocrtTypeEncodings.html%23//
apple_ref/doc/uid/TP40008048-CH100-SW1
If nothing else works, convert the persistent-ID number to NSString,
using an encoding like BASE64 or simply hex in a consistent upper or
lower case. I doubt that the performance cost for a string would be
so high that making your own NSValue subclass would be worthwhile.
-- GG
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
