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?
Reading Inifile values
- If you read in the inifile to a record when the program starts its very ease to reach the information anywhere in the program for ex IniSystemRec.Adress := inifil.ReadString('Server','Adress',''); IniSystemRec.Logging := (inifil.ReadString('Server','Logging','N') = ('J')); Then read values in the program server.Number := IniSystemRec.Number; if IniSystemRec.Test = 'J' then...
- —Guest Ken
Configuration Inside the EXE
- I put my critical configs (like passwords) inside my executable Delphi applications
- —Guest Eduardo Alcantara
- I use binary files to store program configuration data. If the file is damaged or deleted, the program automatically generates a default configuration file. The program provides functionality to copy this file to a custom folder so that users can backup and restore old configurations after reinstalling or moving to another pc.
- —Guest rolandocz
XML in user and global dir
- Classic connection parameters to a database in the global directory, with user and password encrypted. Configuration in users directory using a JVCL storage component
- —Guest Alvaro Castiello
User specific vs application global
- I usually split my storage. User specific data (what was the last record fetched, form positions and so) which will not harm the working of the application I store in the registry (HKEY_CURRENT_USER). If user rights is an issue (shouldn't be, but it's the big IF) it's not of any influence to my application what so ever... Application wide settings (user rights, what is the default export directory and so) I store in the database. For smaller applications this application wide settings will go in an xml structure, so when I make the switch to a database it's with minimal effort... Inifiles are something I said bye bye to a very long time ago, and I don't miss it in any way... And just in general: inifiles/xml/whatever requires user rights, so I really don't understand why it's only mentioned with the registry in the original topic???
- —Guest Norrit
- For storing any kind of configuration data, eg: default login wallpaper (jpeg/png/etc), security codes (binary), most SQL templates used by application (text/memo-encrypted), general settings (INI entries-encrypted). The structure of the table is designed as flexible and efficient as possible.... latest version is always checked upon application startup and also possible to refresh (reload) when the application is already running.
INI Files ??
- I use a type of ISAM.The info is stored and retrieved via a key string and a method constant.The methods are as follows (1)String (2) TStrings (3) TBitMap (4) TIcon (5) TJpegImage (6) TMetaFile (7) TDateTime (8) Integer (9) Int64 (10) Cardinal (11) TListView (12) Double (13) Struct/Record (14) TStream As can be seen,it is more than just a INI Practically nearly every project uses this RTL class as either a INI or whatever. A Key can remain static,but the method must be different or the method may be static but the Key must change. You can overwrite a record,without regard to its data length.At present,a simple XOR encryption is built in.The file is not encrypted as such,on the data content you choose.
- —Guest BazzaWary
- 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.
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.
- 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.