Re: NSUserDefaults -- am I using it correctly?

FROM : Michael Cinkosky
DATE : Thu Apr 21 19:57:12 2005

In case anyone else has had this problem, I thought I would post the
solution.

The issue was that some some very old (and unnecessary) code was
attempting to set a default value for an NSColor.  In previous versions
of OS X, this code was apparently just failing silently, with no side
effects.  (The value was never used in any way, so the fact that it was
failing was not noticed.)  Apparently, the libraries have recently
changed, and this code was causing later attempts to set NSUserDefaults
to fail.  Thus we could set a default value, immediately query that
value and get nil as an answer.  Removing the bogus code cleared up the
problem.

Michael


On Apr 16, 2005, at 3:38 PM, Michael Cinkosky wrote:

>
> Daniel
>
> Thank you very much for your thoughts -- this is quite helpful.  You
> are right to question my understanding of exactly what I should be
> expecting to have happen when I registerDefaults -- I basically knew
> that what you are saying is correct, but I was not thinking it through
> very clearly.  Your message was a big help in that area.  Thanks for
> clearing away some of the fog.
>
> But, as you say, this still leaves the issue of exactly how the code
> could be behaving the way that it is.  I have checked for any place
> where I could be inadvertently setting the user's value prior to
> setting the default value, but there is nothing.  Very strange.
>
> On Apr 14, 2005, at 9:27 PM, Daniel Jalkut wrote:
>

>> Nothing looks wrong that I can see, but I'm concerned about the way
>> you're describing your expectations.
>>
>> Do you realize that "registerDefaults" doesn't write any preferences
>> to disk?  It just sets up the "backup preferences" that will be used
>> in the event that the user doesn't have anything set.
>>
>> So, the only scenario I can imagine where you'd get "nil" back is
>> maybe if the user has a preference set for that value already?  An
>> empty string?  I don't know if that would come back as nil or an
>> empty NSString, but either way it will look "blank" to you on the
>> printout.
>>
>> I would inspect the preferences file on a system where it's failing.
>>
>> Daniel
>>
>> On Apr 14, 2005, at 5:03 PM, Michael Cinkosky wrote:
>>

>>> I have some code that has started not working on some systems, but
>>> after staring at it for several hours, I cannot see why.  Can anyone
>>> spot a problem with this code...
>>>
>>>    // create a mutable dictionary to hold the user defaults
>>>    NSMutableDictionary *stdDefaults = [NSMutableDictionary
>>> dictionaryWithCapacity: 5];
>>>
>>>    // stick something into the dictionary
>>>    [stdDefaults setObject: @"~/Library/MyApp" forKey:
>>> ODLibraryPathPrefKey];
>>>
>>>    // register the defaults
>>>    NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];
>>>    [defaults registerDefaults: stdDefaults];
>>>
>>>    NSLog( @"library path is: %@", [[NSUserDefaults
>>> standardUserDefaults] objectForKey: ODLibraryPathPrefKey] );
>>>
>>> I may have made a typo transferring this into mail, but the
>>> structure of the code accurately reflects what I have.
>>>
>>> The problem I am seeing is that, while this works great on most
>>> systems, there are times when it does not work -- the value returned
>>> in the last statement is nil.  On these systems I cannot get
>>> anything written into the user preferences.  I do not believe that
>>> this is a permission problem, because it happens on a clean install
>>> of the OS.
>>>
>>> So, have I been doing something wrong all along that just shows up
>>> in some contexts?  Or any other ideas?
>>>
>>> All thoughts greatly appreciated!
>>>
>>> Michael
>>> _______________________________________________
>>> MacOSX-dev mailing list
>>> <email_removed>
>>> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>>>

>
> _______________________________________________
> MacOSX-dev mailing list
> <email_removed>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev