Readers Respond: Where and How do you Store your Delphi Application Configuration Data?

Responses: 7

You can also use the Registry - but it can get corrupted. Or, maybe the user does not have privileges to read/write to Registry.

Also, if you know how to store do you know where to store (Application Data, User Data, My Documents...)?

What's your practice? How and where do you store your Delphi application configuration data? Where do you Config?

XML

I generally use INI, but only for smaller applications. When I have a complex layout, I use XML. Obviously, for user security, I encrypt the XML files.

—MichaelRockett

INI and DB

Use appname.ini file for storing client-side app properties (like DB Connection string) and use the database for system wide and user preferences. Here I use a table with two fields - paramname & paramvalue - and have written a TINIfile-like class to access it, e.g. mystring := DBINI.ReadString(Username, 'MyValueName', '');

—Guest Stuart

Why not have the best of both worlds???

I usually store the mundane (non-critical) stuff in a good old INI file. This would include initial form position, colors etc. If the INI file goes missing for some reason you could always regenerate a default INI file from code (in the main form "Create"?). Works fine BUT...if the INI file holds a lot of info you might end up with a lot of code that will normally not be used. So as a solution, set up your INI file with a text editor. then put it into a resource file. Now compile your app to include the resource file. Whenever the INI file goes missing...simply extract it from the resource. This way you 're probably sure that at least you'll have control of a minimum set of defaults. And NO...a resource file containing an embedded INI file does not produce a large overhead on final EXE size.

—intelliflop

Stream.WriteComponent

I see you use TReader/TWriter directly. I use a TComponent wrapper on my TSettings class, making my TSettings a property in the TSettingsComponent wrapper. Then I can simply use Stream.WriteComponent/ReadComponent. That handles also nested classes, eg: a class property insite TSettings. You can add recursion into your routines on tkClass property types to achieve that. By using TReader/TWriter directly as you have done, you can also make it tolerant of invalid property names, by wrapping SetPropValue inside a try...finally. Stream.ReadComponent does not tolerate invalid data, for example if you change your settings class and remove/rename something. This breaks the config file.

—Guest Etherman

INI Files / Stream.WriteComponent

I use a mixture of INI files for simple app data and component streaming for complex data, or data that I want stored in db blob fields. I rarely use the registry, except maybe for service applications.

—Guest Etherman

Simply INI file for maintenance

Hello, I dont see that ini files is dangerous if you know what you are storing in it. simply speaking that INI files is designed to keep application standard params that are not critical for users nor admins, for instance you must not store privileges inside it but your must store database connection init cuz one day you may face a maintenance case that make your life complicated if you used streams or encryption.

—Guest MB

Ini files custom TAppConfig class

Most of the time I do INI files. I have a class TAppConfig with bunch of properties and methods. Save/Load that saves and loads to/from the INI file. Since the info is not "only-for-app-eyes" and the app will survive if it is not present, I can use INI with no issues.

—rascal1936