On 2009 Dec 12, at 22:47, Joar Wingfors wrote:
> That's strictly speaking only true for NSDictionary, where you can't
> configure how keys are added to the dictionary. CFDictionary allows full
> control over that, and doesn't even require for the keys to be objects.
OK, I ammended the bug to e
On 12 dec 2009, at 22.04, Jerry Krinock wrote:
>> And although NSDictionary and CFDictionary objects allow their keys to be
>> objects of any type, if the keys are not string objects, the collections are
>> not property-list objects.
>
> Actually, there's a third bug, since that statement is i
On 2009 Dec 12, at 10:20, Chris Parker wrote:
> And although NSDictionary and CFDictionary objects allow their keys to be
> objects of any type, if the keys are not string objects, the collections are
> not property-list objects.
Actually, there's a third bug, since that statement is incorrect.
As Clark noted elsewhere, you're using a string key properly with
NSUserDefaults itself and NSUserDefaults and CFPreferences both require that
the entire subtree of the value be a properly formed property list object.
For NSDictionaries that means all keys must be strings for the entire tree. Th
On 12 Dec 2009, at 14:58, Jerry Krinock wrote:
>
> On 2009 Dec 11, at 23:21, Clark Cox wrote:
>
>> The message printed is unfortunate, as it doesn't really tell you what
>> is wrong (please file a bug). It's fine to have numbers as keys in
>> dictionaries; however keys property lists (and there
On 2009 Dec 11, at 23:21, Clark Cox wrote:
> The message printed is unfortunate, as it doesn't really tell you what
> is wrong (please file a bug). It's fine to have numbers as keys in
> dictionaries; however keys property lists (and therefore in user
> defaults) must be strings.
Well, maybe the
On Fri, Dec 11, 2009 at 11:10 PM, Jerry Krinock wrote:
> Sorry for the wonky subject. It's easier to explain in code:
>
> NSNumber* innerKey = [NSNumber numberWithInt:0] ;
> NSDictionary* dic = [NSDictionary dictionaryWithObject:@"Hello"
> forKey:inn
