Best place to write path into registry

[NewsArchive]

I have been writing the path to my program into
Hkey Local Machine\software\garagepartner\localpath

Now I am manifesting using SB7 and the program is manifested asinvoker
Do I need to change where I am writing the Path?

--

Dan Scott
C55 C6.3 C7.1 LEGACY
www.garagepartner.com

King of questions for Clarion Third Party

Plan A is always more effective when the device you are working on
understands that Plan B involves a larger hammer

[NewsArchive]

Dan,

> I have been writing the path to my program into
> Hkey Local Machine\software\garagepartner\localpath
>
> Now I am manifesting using SB7 and the program is manifested asinvoker
> Do I need to change where I am writing the Path?

I assume you do not write the path from your own app to the registry but you
let SetupBuilder do it for you (in this case you don't need to change
anything). If your app is "asInvoker" manifested then you can still read
the HKLM registry key.

Friedrich

[NewsArchive]

Friedrich

Sometimes the user may change the program location AFTER the install.
So when an update is installed, I need to know where the new folder
location is.

Dan

--

Dan Scott
C55 C6.3 C7.1 LEGACY
www.garagepartner.com

King of questions for Clarion Third Party

Plan A is always more effective when the device you are working on
understands that Plan B involves a larger hammer

[NewsArchive]

Dan,

> Sometimes the user may change the program location AFTER the install.
> So when an update is installed, I need to know where the new folder
> location is.

No problem. Then you have to copy it to a per-user location from your
application.

If you have to install "per-user" data, install it to a common location and
as a "first run" action of your main application, copy the data from the
common location into a per-user location.

In other words, do not change anything in the installer. You still write to
HKEY_LOCAL_MACHINE. But as a "first run" action of your application, copy
the default folder from HKEY_LOCAL_MACHINE to a per-user registry location
and you are done.

Please note that you can't and should not uninstall per-user data (that is
by Windows design and expected).

Friedrich

[NewsArchive]

As Friedrich said, if your app is manifested and not virtualized there's no
problem *reading* from the "real" HKLM registry.

And if your program may be used by more than one user logon on any machine
(which would mean different HKEY Current User instances), then HKLM is the
best consistent place to store that information.

Because I know some users are tweakers and may move things around, what I
often do is to have the installation program write the path and the current
date to HKLM.

I have the app write the current path and date to HKEY Current User each
time it's run.

Any time I need the information, I can read both locations and use whichever
is newer.

Jane

[NewsArchive]

Jane

See my reply to Friedrich.
Problem is if they decide to change the program location after the install.

Dan

--

Dan Scott
C55 C6.3 C7.1 LEGACY
www.garagepartner.com

King of questions for Clarion Third Party

Plan A is always more effective when the device you are working on
understands that Plan B involves a larger hammer

[NewsArchive]

Dan

See my reply.

That's what my solution addresses.

jf

[NewsArchive]

Sorry Jane, misread.

Anyway... HKEY Current : Does this open a key for each user, or does any
current user write to one particular key?
Reason I ask is that they may change users 10 times a day.

--
Dan Scott
C55 - C6.3 Legacy
Garage Partner Pro / Invoice Partner
www.garagepartner.com
Plan A is always more effective when the device you are working on
understands that Plan B involves a larger hammer

[NewsArchive]

Each user BECOMES current user when he's logged on.

If you're using the registry, you really only have two options.
1. per-user, written to HKEY Current User. Each user will have his own
separate copy of the information stored here.
2. for everybody on the machine, written to HKEY Local Machine. Everybody
can read from HKLM and will always see the same information. But to WRITE
to it requires elevation.

Jane Fleming

[NewsArchive]

Jane

Still having a problem wrapping my head around this.
If user 1 logs on and changes the location of my program to
c:\myprogram and then logs off, when user 2 logs in, does he start with
a blank slate in current User. If so, then I can't use current user as
the next user
will not know where the program is.
I am thinking that I should only let Adminstrators change the program
folder.

Dan

--

Dan Scott
C55 C6.3 C7.1 LEGACY
www.garagepartner.com

King of questions for Clarion Third Party

Plan A is always more effective when the device you are working on
understands that Plan B involves a larger hammer

[NewsArchive]

Hi Dan,

> Still having a problem wrapping my head around this.
> If user 1 logs on and changes the location of my program to
> c:\myprogram and then logs off, when user 2 logs in, does he start with
> a blank slate in current User. If so, then I can't use current user as the
> next user will not know where the program is.
> I am thinking that I should only let Adminstrators change the program
> folder.

That's why you should, as a "first run" action of your main (asInvoker =
per-user) application, copy this kind of data from the common location into
a per-user location.

For example:

1. Installer writes the "default" to:

HKEY_LOCAL_MACHINE\Software\GaragePartner\LocalPat h

2. JoeUser logs-in and starts the app for the first time.

Your app detects that there is no
HKEY_CURRENT_USER\Software\GaragePartner\LocalPath entry and copies it from
HKLM to HKCU. JoeUser can now change its local path and it is stored in the
HKCU key.

3. JohnWayne logs-in and starts the app for the first time.

Same story. Your app detects that there is no
HKEY_CURRENT_USER\Software\GaragePartner\LocalPath entry and copies it from
HKLM to HKCU. JoeUser can now change its local path and it is stored in the
HKCU key

4. Okay, JoeUser logs-in again and this time your app detects that the HKCU
already exists and reads the path. JoeUser and JohnWayne have different
LocalPath entries.

Friedrich

[NewsArchive]

"JoeUser and JohnWayne have different
LocalPath entries."

This what I don't want to happen. I am thinking of simply requiring
administrator provilege to change the program path. May have a seperate
small program to change path that requires administrator.

Am i being too thick?



On 8/31/2011 12:30 PM, Friedrich Linder wrote:
> JoeUser and JohnWayne have different
> LocalPath entries.

--

Dan Scott
C55 C6.3 C7.1 LEGACY
www.garagepartner.com

King of questions for Clarion Third Party

Plan A is always more effective when the device you are working on
understands that Plan B involves a larger hammer

[NewsArchive]

Not at all.

That's what I do for changing data paths.

As an example, I have an app that stores data path locations in the HKEY
Local Machine hive of the registry.

To alter that path (or set up alternate paths that can be selected with a
command-line switch), the app has a button that uses ShellExecute to open a
separate helper app that has a requireAdministrator manifest. (You need to
use ShellExecute. Clarion's RUN command will not launch an elevated app
from a non-elevated program.)

That app then writes to HKEY Local Machine, so the information is available
to all users.

When you said "change the path to my program", I thought you meant that
users were physically moving your program from one folder to another one.

jf

[NewsArchive]

> When you said "change the path to my program", I thought you meant that
> users were physically moving your program from one folder to another one.

That may happen too. Thanks for the hint on using Shell Execute.

Dan

--
Dan Scott
C55 - C6.3 Legacy
Garage Partner Pro / Invoice Partner
www.garagepartner.com
Plan A is always more effective when the device you are working on
understands that Plan B involves a larger hammer

[NewsArchive]

I actually still use an INI file. Basically the only thing in it is the
datapath.

It's read on startup and it resides in the Program Files folder. There
is no problem for normal users to read it.

Then I have a DataManager application that requires admin privileges .
It manages the INI file (running elevated allows writing to the ini) and
allows a user to move datafiles to a new location.

Works on everything from XP to Win7x64 with NO registry entries. I
still do not like the registry...<g>

Paul MacFarlane