Hi,

I've just been challenged by an administrator of the computer systems of one
of my clients to change the way I develop my applications, which I thought
I'd run by this community to get some thoughts on.  

In the past, I used to store my users settings in the registry. I have now
changed to storing them in ini files in the same directory as the
executable.

I have had it pointed out to me that this is not ideal for server based
terminal sessions (such as Windows Terminal Services or Citrix sessions),
and that I should change my application so all settings are stored in the
database (and not on either ini's or the registry). - I guess I would have
to have *some* settings still outside, else the application would not know
where to look for the data.

At the moment, I store general settings (such as grid layouts, certain user
preferences, etc) as well as the data location in the ini files using Jedi's
formstorage and inistorage components. (oh, and some ini files are generated
with quantumgrid)

My application will usually run on workstation environments, and not
terminal environments, with a few exceptions.

Does anyone want to put their 2c worth as to what they recommend is the best
approach for storing individual user settings?

Cheers

Adam.

Adam


I'm on his side With the exception of TMaN where I wanted to be able to edit the settings via notepad (TMaN is my OE replacement and I wanted to do that in case I needed to stop it checking email on startup) all my apps store user data in the database. There is a text file giving the path to the data information but that's about it.

In one case only do I store anything in the registry - one app allows double clicking a phone number to dial it, the com port and timeout values are stored in the registry since these are machine specific. I could add them into the tables but then I'd have to jump through loops to check which pc is which.

Roy Lambert

Hi Roy,

> I'm on his side

Gee... thanks!  

Seriously though - I'm wanting to learn. If no one has anything negative to
say about it, I might just have to make some mods to my app.

I think the JVFormstorage components can still be used with some tweaking,
but I'll have to revisit the quantumgrids.

Cheers

Adam.

Adam,

As a systems administrator I've come across this problem from both sides
of the fence! From a programming perspective it is very neat to store
all settings in the program folder or HKLM part of the registry. In fact
there is nothing wrong with this for settings which are global to the
program and which define systems settings which never change. However
difficulties can occur if users do not have administrator rights on
their PCs. Then you are faced with having to get the systems
administrator to change permissions on the application
directory/registry to allow non admin users to write access (or build
this into your program's installer)
To keep systems administrators happy (and this is MS recommendation) you
should store user settings in the user's profile. In practice this means
storing in the HKCU part of the registry or the folder structure under
CSIDL_LOCAL_APPDATA (%USERPROFILE%\Local Settings\Application Data)
Bear in mind that by using these locations you are possibly future
proofing against any gotchas that Vista will introduce,

Rgds,
Steve

Steve


My view is that the registry is way overworked already don't use it unless you have to or there's a very good reason to do so.

Roy Lambert

Roy,

One bonus of using the registry is it very easy to get the users profile  -
just replace HKLM with HKCU in all registry references. If you're going to
store data as a file thats user specific then you need the extra little bit
of work to get the relevant CSIDL folder.
In the early days I was a big fan of the registry since users didn't mess
about in there much. But over the past year or two I notice an increase in
the level of user acceptance of regedit. I've now come around to storing
settings as files (ini or binary) in the CSDIL folders as users never look
there and if something gets deleted it can generally be recovered from the
recycle bin. The initial out of the box settings for an appliacation I would
always store as a file in the program folder.
If its more than one or two settings I use StorageLib
(http://www.deepsoftware.ru/rsllib/)

Steve


"Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message
news:7430F596-7D86-4474-BF39-9AF0D0DC46FC@news.elevatesoft.com...
> Steve
>
>
> My view is that the registry is way overworked already don't use it unless
> you have to or there's a very good reason to do so.
>
> Roy Lambert
>

"Adam H." <ahairsub4@rREMOVEMEspamSTOPPER.jvxp.com> wrote in message
news:9DA0A477-8B6F-4C37-9A07-0BB3AE7E7CEE@news.elevatesoft.com...
> Hi,
>
> I've just been challenged by an administrator of the computer systems of one of my clients to change the way I develop my
> applications, which I thought I'd run by this community to get some thoughts on.  
>
> In the past, I used to store my users settings in the registry. I have now changed to storing them in ini files in the same
> directory as the executable.
>
> I have had it pointed out to me that this is not ideal for server based terminal sessions (such as Windows Terminal Services or
> Citrix sessions), and that I should change my application so all settings are stored in the database (and not on either ini's or
> the registry). - I guess I would have to have *some* settings still outside, else the application would not know where to look for
> the data.
>
> At the moment, I store general settings (such as grid layouts, certain user preferences, etc) as well as the data location in the
> ini files using Jedi's formstorage and inistorage components. (oh, and some ini files are generated with quantumgrid)
>
> My application will usually run on workstation environments, and not terminal environments, with a few exceptions.
>
> Does anyone want to put their 2c worth as to what they recommend is the best approach for storing individual user settings?
>
> Cheers
>
> Adam.
>

The Registry is a database
what you really mean was Delphi provides ways
of communicating with the registry and you
didn't want to duplicate the effort writing it
to your own database registry structure

I always use a database ini file with a default for "undiscovered"
connections its the only way to ensure control over the system

gF
gF

Steve

>One bonus of using the registry is it very easy to get the users profile

At least until they replace their PC , reinstall/upgrade Windows (or simply move to a different desk) then its "slightly" more difficult - however if its stored in a table as part of the app .....

>In the early days I was a big fan of the registry since users didn't mess
>about in there much.

Maybe users didn't but developers and software houses certainly did. I'm sure that a large number of Windows reinstalls over the years have been attributable to nothing more than the registry and its use/misuse.

Roy Lambert

GregF


>The Registry is a database

Yeah but its a naff one <vbcg>

Roy Lambert

Here's a link I bookmarked a while back on the subject:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw2kcli/html/W2Kcli_chapter4.asp


Jim


> Hi,
>
> I've just been challenged by an administrator of the computer systems of one
> of my clients to change the way I develop my applications, which I thought
> I'd run by this community to get some thoughts on.  
>
> In the past, I used to store my users settings in the registry. I have now
> changed to storing them in ini files in the same directory as the
> executable.
>
> I have had it pointed out to me that this is not ideal for server based
> terminal sessions (such as Windows Terminal Services or Citrix sessions),
> and that I should change my application so all settings are stored in the
> database (and not on either ini's or the registry). - I guess I would have
> to have *some* settings still outside, else the application would not know
> where to look for the data.
>
> At the moment, I store general settings (such as grid layouts, certain user
> preferences, etc) as well as the data location in the ini files using Jedi's
> formstorage and inistorage components. (oh, and some ini files are generated
> with quantumgrid)
>
> My application will usually run on workstation environments, and not
> terminal environments, with a few exceptions.
>
> Does anyone want to put their 2c worth as to what they recommend is the best
> approach for storing individual user settings?
>
> Cheers
>
> Adam.
>
>