on 5/26/08 5:27 AM, email@hidden at
<email@hidden> wrote:
> Our application currently stores preferences in ~/Library/Preferences
> (or, more strictly, in the folder identified as kPreferenceFolderType
> with FindFolder; doubtless deprecated but the code runs nicely for
> our users with non-up-to-date systems).
>
> Based on a customer suggestion, we see the idea that the correct behaviour
> for our
> application would actually be to look in ~/Library/Preferences
> first, then /Library/Preferences; if found in the second location
> use it and attempt to rewrite there; silently write a new copy
> to ~/Library/Preferences if /Library/Preferences/... is unwriteable.
>
> 1. Does this describe correct semantics for preference files? (Is
> there a reference - I'm sure I've read all about this, but I can't
> find it today)?
All this is an "implementation detail" that you shouldn't have any need to
know. If you use the CFPreferences API's everything will "just work" (Apple
Inc.).
> 2. Should we get around to using up-to-date APIs, is there one which
> would support us in this in high level access ("find/create a
> preferences file") which does not require the preferences to be
> a plist?
Sure, the CFPreference API's abstract all the gory details of locations on
disk and file formats. The only requirement is that you have to use
CFObjects parameters when calling the APIs.
--
Enjoy,
George Warner,
Schizophrenic Optimization Scientist
Apple Developer Technical Support (DTS)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
This email sent to email@hidden
