classPreferences on GitHub

I have written a small class to store and retrieve applications settings/preferences. It should work fine cross platform but I have only tested on OSX. Very simple to use, the constructor generates your prefs file if it does not already exists for your app. You then use the get and set methods to store and retrieve your settings/preferences.

I have posted it to GitHub, it would be good to have some contributions/additions and feedback.

Hope it is of use to some of you.

https://github.com/CharlieXojo/classPreferences

The way I use it is add a property to my App called Preferences and then in my app open event add:

  Preferences = new classPreferences("com.yourbundle.id") 

Job done, you can then use the methods as described on GitHub to store your preferences/settings.

Does it happen to use NSPreferences/CFPreferences on OS X ?
If not you won’t be able to use it in an App submitted to the App store
And sandboxed apps on OS X may not work correctly either (I’m less certain about this one)

Nope, but now its on github hopefully someone will contribute and it will have.

It writes to application support folder, I thought we could write anything there?

I have a question about app support folder naming. I’m a huge fan of being able to find things, so folder names that match app names are incredibly useful and friendly. Somewhere along the way some idiot decided to start using reverse-domain identifiers in app support and it’s really annoying. I don’t want to have to look up your reverse domain identifier to find things.

Is it a requirement to name your app support folder horribly for the app store? Or does the world just hate usability?

I’m not sure if it is a requirement. Many in my app support folder don’t use a bundleID and simply a company name. I think bundleIDs just ensure uniqueness and would normally only be used in places your average joe would not need to look. I think they are quite good, at least they didn’t opt for uuid’s for unique folder names.

[quote=114745:@Norman Palardy]Does it happen to use NSPreferences/CFPreferences on OS X ?
If not you won’t be able to use it in an App submitted to the App store
And sandboxed apps on OS X may not work correctly either (I’m less certain about this one)[/quote]
Norman, I’m not sure what you have said here is at all correct. My class writes a sqlite file. I can put this in app support folder. Can you elaborate on your 2 points?

If you write a standard preferences file to the Preferences directory you have to use NSPReferences / CFPreferences.

If you write it to some other permissible location then your preferences are in a non-standard location in a nonstandard format and you can probably write whatever you want.

There is a few things missing from that class …
Does not support COLOR, FOLDERITEM, or SINGLE (defaults to DOUBLE)

An alternative you might be interested in is my INI_CLASS (uses a textfile not a database), supports all the datatypes, and uses overloading so you only need to worry about PUT and GET … the datatype is automatically overloaded for you.

I really need to factor out our Preferences handling from the IDE so you can just use it in your app and not worry about this

It uses CFPreferences on OS X, the registry on Windows & a hidden named file in your home dir on Linux (which is pretty standard)

[quote=114928:@Norman Palardy]I really need to factor out our Preferences handling from the IDE so you can just use it in your app and not worry about this

It uses CFPreferences on OS X, the registry on Windows & a hidden named file in your home dir on Linux (which is pretty standard)[/quote]
Well it would be nice :wink:

Please don’t support the registry for saving preferences in Windows. I never used it in any of my windows programs. Such a bad, complex and confusing thing like the registry shouldn’t be supported.

Just my 2 cent.

[quote=114944:@Torsten Gaidies]Please don’t support the registry for saving preferences in Windows. I never used it in any of my windows programs. Such a bad, complex and confusing thing like the registry shouldn’t be supported.
[/quote]
Its the recommended way of handling application settings
INI files etc are not recommend any longer while they still work
The registry can be located on a local machine or on a remote machine (or combinations of part local part remote or wholly local or wholly remote)
It’s the “correct” way to handle preferences on Windows

Really.

It may be the correct way, because Microsoft suggest it. But it isn’t the right way. Microsoft could do better, to keep their system KISS.

Personaly I’ won’t store any data in the registry. So I hope, that there is an additional preference storing possibility, like saving to a given FolderItem.

My customers should be able, to easyly copy and paste their data and settings from one system to another.

You either store pref/config data in the platform vendors “correct” manner, or you develop a “xplat” version that does the job and requires no platform specific interaction, such as I did :slight_smile: … which also allows for pref/config data to be moved/copied at wil

[quote=114958:@Torsten Gaidies]It may be the correct way, because Microsoft suggest it. But it isn’t the right way. Microsoft could do better, to keep their system KISS.
[/quote]
Petition MS for that :stuck_out_tongue:

Not in our classes.
We use the recommended way so that should our software be used in an enterprise setting with floating profiles etc it all works without any additional work on the part of network admins etc.
The same can’t necessarily be said of other schemes.

But this is all theoretical until / unless we do factor ours out of the ide & put it in the framework

I have done it, and now Ballmer has gone :stuck_out_tongue:

Norman, I know you will do it the right way ;).

Dave, do you have a downloadable class for the settings?

[quote=114915:@Dave S]There is a few things missing from that class …
Does not support COLOR, FOLDERITEM, or SINGLE (defaults to DOUBLE)

An alternative you might be interested in is my INI_CLASS (uses a textfile not a database), supports all the datatypes, and uses overloading so you only need to worry about PUT and GET … the datatype is automatically overloaded for you.[/quote]
Just out of interest Dave, using overloads as you described if i did PUT(1.1) how do you know if its a single or double? Or would you just save it as a single due to its size? Then what do you return when I say Get(“MyOnePointOneVal”), do you return a single?

[quote=114952:@Norman Palardy]Its the recommended way of handling application settings
INI files etc are not recommend any longer while they still work
The registry can be located on a local machine or on a remote machine (or combinations of part local part remote or wholly local or wholly remote)
It’s the “correct” way to handle preferences on Windows[/quote]
That’s interesting because in .NET Microsoft recommends using app.config files for preferences.

Anyway, back on topic.

Thanks to @Axel Schneider for contributing his setSingleValue, getSingleValue, setColorValue and getColorValue methods. I have also added default value to the get methods of classPreferences so if a value does not exists in the key requested the default value is returned rather than a keyNotFoundException.

Those are more like PLIST files for app bundles on OS X

http://msdn.microsoft.com/en-ca/library/1xtk877y(v=vs.90).aspx