Rob,
Let's just say it seemed like a lot of entries to me! <g> I only
use the Registry where absolutely needed and have always depended on
ini-files for the rest, but in this app even optional color choices for
panels and such were stored under this app's registry settings! But at
least calls weren't made individually. There was one unit with maybe 10
methods in it to handle the reading and writing. What WAS bad I thought was
that the reg was opened and kept opened throughout the program session. I
had been told by someone a long time ago that doing so was not good practice
because it could lead to corruption...that's what I meant by dangerous.
Also I again used the wrong wording to explain what I meant. When I
said that I kept the ini-file open throughout the session I just meant that
the var of type Inifile was in memory and freed until the program closed.
I've never considered this to be a problem and doing so requires a lot less
coding or the use of global variables to hold data. I simply read directly
from and write directly to the ini-file as needed when needed. I was pretty
sure that TIniFile didn't place the entire file into memory as TMemInifile
does, and having tried both methods I didn't observe any performance
differences, so why cache the entire file I figured.
And yes, I was referring to an ini-file when I said other structures
below. Except for the aliaspath itself, which I'll hold in the registry
nearly everything else can be stored in and retrieved from a table under the
same database connection. The big question about using this method is
whether or not doing so will expend more resources and use more cycles than
a traditional ini-file approach would. Also, this will depend upon how I
lookup data within the table. If I index value names as an ini-file does
and use findkey or if I perhaps index each value based on an ID number and
use gotoKey, the indexed ID being directly related to a group of constants
or an enumerated set. And finally the last consideration would be whether
to use an in-memory table for this or not.
Were this a multi-user environment I'd definitely use the mem-table
for each user and fill it from a query done against a single table that held
all user's data, but in this particular case, where only one user will be on
at a time, I don't know that the time saved by using an in-mem table would
be worthwhile.
One thing is for sure however, and that is that I would never even
consider using a db to hold such data unless a dB was already required by
the application!
from Robert Meek dba Tangentals Design CCopyright 2006
"When I examine myself and my methods of thought, I come to the conclusion
that the gift of Fantasy has meant more to me then my talent for absorbing
positive knowledge!"
Albert Einstein
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Rob Kennedy
Sent: Wednesday, March 22, 2006 11:34 PM
To: Borland's Delphi Discussion List
Subject: Re: More questions on code use and structure
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
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
