FROM : Chris Parker
DATE : Thu Jan 09 22:34:17 2003
Hi folks -
On Thursday, January 9, 2003, at 2:04 AM, Pierre-Olivier Latour wrote:
>> There is likely no domain being specified to use to store the
>> defaults in. Normally this is picked out of the Info.plist key
>> CFBundleIdentifier in the application wrapper.
>
> Unfortunately, there is one and it works, because if I do this before
> calling synchronize:
>
> [defaults setBool:[defaults boolForKey:kKey_LogFile]
> forKey:kKey_LogFile];
>
> A default file is then saved to disk, but contains only the key
> kKey_LogFile.
>
> So obviously, synchronize only saves the keys that have been "touched"
> since
> the defaults were registered. That's understandable, but I don't think
> this
> is what the doc says i.e. defaults should be written to disk even if
> they
> have not been updated.
>
>> You need to set the identifier in the target of your application..
>> unless it is a wrapperless tool.. Instead you're going to have to set
>> the domain programmatically.
>
> Maybe I could workaround the problem with that - who knows... How
> would you
> do this?
Sounds like we might need some doc improvement in this respect as to
whether the registration domain gets written out. There's a brief
discussion of this in the "User Defaults" programming topic at
http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/
ProgrammingTopics/UserDefaults/index.html making the statement that the
registration domain is volatile.
When you register a defaults dictionary using -[NSUserDefaults
registerDefaults] those keys and values are placed in the registration
domain. We don't write those defaults out to disk, even though they
wind up in the search path.
So key/value pairs that your application registers aren't written out -
they're fallback values if other values for those keys haven't been
brought up from disk.
Pierre, what's happening in your case is actually the correct behavior.
You've registered a bunch of key/value pairs in the dictionary, but the
only one you've set via the set<something>:forKey: API is the logfile
one. That key/value pair gets written out but the registered defaults
don't.
.chris
--
Chris Parker
Cocoa Frameworks Engineer
Apple Computer, Inc.
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
DATE : Thu Jan 09 22:34:17 2003
Hi folks -
On Thursday, January 9, 2003, at 2:04 AM, Pierre-Olivier Latour wrote:
>> There is likely no domain being specified to use to store the
>> defaults in. Normally this is picked out of the Info.plist key
>> CFBundleIdentifier in the application wrapper.
>
> Unfortunately, there is one and it works, because if I do this before
> calling synchronize:
>
> [defaults setBool:[defaults boolForKey:kKey_LogFile]
> forKey:kKey_LogFile];
>
> A default file is then saved to disk, but contains only the key
> kKey_LogFile.
>
> So obviously, synchronize only saves the keys that have been "touched"
> since
> the defaults were registered. That's understandable, but I don't think
> this
> is what the doc says i.e. defaults should be written to disk even if
> they
> have not been updated.
>
>> You need to set the identifier in the target of your application..
>> unless it is a wrapperless tool.. Instead you're going to have to set
>> the domain programmatically.
>
> Maybe I could workaround the problem with that - who knows... How
> would you
> do this?
Sounds like we might need some doc improvement in this respect as to
whether the registration domain gets written out. There's a brief
discussion of this in the "User Defaults" programming topic at
http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/
ProgrammingTopics/UserDefaults/index.html making the statement that the
registration domain is volatile.
When you register a defaults dictionary using -[NSUserDefaults
registerDefaults] those keys and values are placed in the registration
domain. We don't write those defaults out to disk, even though they
wind up in the search path.
So key/value pairs that your application registers aren't written out -
they're fallback values if other values for those keys haven't been
brought up from disk.
Pierre, what's happening in your case is actually the correct behavior.
You've registered a bunch of key/value pairs in the dictionary, but the
only one you've set via the set<something>:forKey: API is the logfile
one. That key/value pair gets written out but the registered defaults
don't.
.chris
--
Chris Parker
Cocoa Frameworks Engineer
Apple Computer, Inc.
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
| Related mails | Author | Date |
|---|---|---|
| Pierre-Olivier Lat… | Jan 8, 21:51 | |
| Robert Cerny | Jan 9, 09:12 | |
| Scott Anguish | Jan 9, 10:18 | |
| Pierre-Olivier Lat… | Jan 9, 11:04 | |
| Marco Binder | Jan 9, 15:44 | |
| Alex Rice | Jan 9, 16:18 | |
| Mike Ferris | Jan 9, 19:47 | |
| Pierre-Olivier Lat… | Jan 9, 20:24 | |
| Pierre-Olivier Lat… | Jan 9, 20:25 | |
| Chris Parker | Jan 9, 22:34 |






Cocoa mail archive

