How do you prefer to store application settings?
How do you prefer to store application settings?
Which component/library do you prefer for this task?
Using TRegistry seems to be not optimal for me
Which component/library do you prefer for this task?
Using TRegistry seems to be not optimal for me
I prefer INI and XML, but that's mostly out of habit and ease of access to resulting files.
ReplyDeleteIt's hard to beat the good ol' INI file.
ReplyDeleteWe use Delphi's Component streaming for that purpose - works like a charm.
ReplyDeleteI just serialize/deserialize my object which contains all the application settings using my serializer (https://code.google.com/p/delphi-oop/wiki/SvSerializer).
ReplyDeleteKrom Stern Did you try YAML ? I like it syntax
ReplyDeleteplease don't use registry at all, XML and now "deprecated" INI handles all your needs easily.
ReplyDeletehave a look at omnixml, you can define a class with published fields that you can serialize/load to/from xml with just 1 line of code(but it can do much more than that)
http://code.google.com/p/omnixml/
Dorin Duminica Why dont you like the registry ?
ReplyDeleteto answer with a question: what makes registry so special that a third party application should write anything to it?
ReplyDeleteI see no valid reason for an application(that is not part of the OS) to write anything to it, even read for that matter... use API's
Linas Naginionis
ReplyDeleteNice, that SvSerializer also serializes enumerable types. I will definitely give it a try. One question though: Does SvSerializer also support record properties out of the box ?
No one mentions JSON which is way more human-friendly than XML? If your Delphi supports enhanced RTTI and you use SuperObject, you can directly call ToJSON() and FromJSON() upon your settings objects, check the following class helper for TObject defined in SuperObject:
ReplyDeleteTSuperObjectHelper = class helper for TObject
public
function ToJson(ctx: TSuperRttiContext = nil): ISuperObject;
constructor FromJson(const obj: ISuperObject; ctx: TSuperRttiContext = nil); overload;
constructor FromJson(const str: string; ctx: TSuperRttiContext = nil); overload;
end;
Markus Joos Yes, records are also supported. Same as other classes, lists, containers from Generics.Collections, etc. Also SvSerializer can use json or xml as output format.
ReplyDeleteFor Form & UI stuff, I use TFormStorage from ante-diluvian RxLib :)
ReplyDeleteFor the rest, straight ini & json.
ini when settings are simple (because the file is very simple to edit, and everybody knows how to edit one)
json for more complex settings (because json is simpler to read and edit, and generally more human-friendly than xml)
We use a system derived from jvcl TjvFormStorage / TjvAppStorage. It writes settings to an .ini file and form positions to the registry.
ReplyDeletethe component/library is self-written and not of much interest but the main point is: i am using XML for storing and retrieving such settings.
ReplyDeleteDepends on what type of setting it is. Global applicationsettings for all users is modelled and stored as object in database. There is also a lot of settings in the ini-file as it is easy to add and change. Personal user settings is stored in a xml-file. We never use the windows registry for anything to avoid problems.
ReplyDeletesome time ago I wrote simple unit for storing settings in INI-file. it uses rtti and allows to use compile-time check. To add new section and property to ini-file you shuold simply add and register new settings class like:
ReplyDelete[Section('section1'')]
TDBOptions = class(TBase)
[DefaultValue['80']]
property Port : integer index 0 read getIntValue write setInvValue;
end;
there is no implementation code at all, just register this class.
I wrote article in my blog, but it is in russian, in the end of the article there is a link to source code http://teran.karelia.pro/articles/item_4506.html take a look at it, may be you will find it useful
I always use INI file. Sometimes, values are encode for complex datatype for which I always write ToString and FromString methods which in turn are used to write/read INI file.
ReplyDeleteI prefer INI-file. Easy to write, easy to read, easy to move between computers :)
ReplyDeleteI'm an INI guy, but then you have the question of where to put them. Originally in the windows directory or app directory, now it needs to be somewhere in the users directory.
ReplyDeleteWe use registry or .ini to identify a database where the rest of the settings are stored.
ReplyDeleteUsing Registry is trivial (assuming you follow MS's guidelines), with the exception of moving settings from one machine to another - but - in these cloud days - data rarely are local anyways.
+1 for ini files, we also store settings in the DB.
ReplyDeleteThe point of the registry is to be "platform compliant" a bit - people do search the registry. I do registry when i code reusable code shared between applications and services. Going .ini you'll need to fiddle a bit more to make sure it can be read and written under different accounts, windows versions et. al. Registry actually simplifies that imho.
ReplyDeleteThat said - the way you serialize you properties is not ini or registry or xml/json dependent. All of these formats can handle a "blob".
Having read some of the comment i will write my next serializer based on OmiXML because i love the library. All credits to JSON but well written XML is much easier to read and edit imho.
How about ini files?
ReplyDeletea Text file would be enough. no matter it is INI / JSON /XML or what else.
ReplyDeletemelice huang a text file is not enough as a definition for a way to store data: you need to format the text, for example as an INI or XML file. Performance is also important sometimes. XML could be incrediblys slow compared to INI file. And code required to encode/decode it has a large footprint. This is - IMO - completely overkill for storing applications settings.
ReplyDeleteThanks to all for your opinions
ReplyDeleteI personally like JSON serialization / deserialization with superobject library
ReplyDelete