Robert Meek wrote: > I know many of you are now using xml in place of the common ini-file > for storing and retrieving application options and the like but I've never > heard from any of those doing this how they feel it compares as far as > speed, resource usage, etc. > Recently I had to finish up some work on a project I didn't > originally write but which had well over 200 hundred entries to the > registry! I'm not kidding!
That's not really very much. Ever looked at the HKCU\Software\Borland key? What's bad is if the program had special code to store each of those 200 settings. Instead, I hope there was something in place to generalize the settings, so there aren't more than a few routines to manage everything at once. > A large percentage of these were basic optional > settings used throughout the lifetime of the app, and the original > programmer wriote a global unit which set it up and kept the reg open while > during the entire lifetime of the application. Just because it was the > registry I didn't like this much, even though I myself have done somewhat > the same using ini-files. So I was curious having never seen anything done > this way before, is this acceptable practice? http://blogs.msdn.com/oldnewthing/archive/2006/02/22/536920.aspx > Isn't doing so somewhat dangerous? Dangerous? In what way? > As I said I've often used ini-file much the same way, opening the > file at the application's start and keeping it alive so that I could read > settings directly from within it without having to re-open and close it all > the time or use variables to hold the data needed, with the tiniFile var > being my one last use of a global variable I still allow. TIniFile doesn't keep the file open. All it does is call the INI-file-related API functions. Whether the OS keeps the INI file open between calls is up to the OS. The interface to INI files is stateless, though, so there's nothing that would require the file to be kept open any longer than it takes to read or write a single value. TMemIniFile doesn't keep a file open, either. It loads the entire file into memory and then manages everything itself. TRegIniFile and TRegistryIniFile keep a registry handle open, mainly because they contain an instance of TRegistry. > Now in another application I'm about to start, a database is used to > control most of the mechanics. It's not a db app per say, but it does > depend upon a database and a number of local tables in order to function. > Most of this is hidden from the user, with all inserts, edits, deletions, > and posts being handled internally without their input or knowledge. Good. That's how database-using programs should work. > And in > this situation I'm considering making use of a separate db table to hold all > configuration and optional data because the database will be running during > the life of the application anyway. It seems almost ludicrous to need to > create and use yet another structure type just for this one need when a > perfectly sound device is already available! The "other structure type" -- are you talking about the INI file, since the database is already available in the program? Or do you mean adding another table to the database would be ludicrous since you've already mastered the technique of using INI files? Note that you'll have to have at least *some* data outside the database. In particular, you can't store database connection settings in the database since you'll need to have them before you could retrieve them. You should probably also store language-selection settings externally. Otherwise, you won't know what language to display your error messages in when you can't connect to the database. -- Rob _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
