jo said:
I'll have a look at this when I reinstall VB6
There are non VB-prog alternatives, for frontend to that registry key,
{HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths]
..
One is AppPaths by Gregory Braun. It runs as a 60k .cpl executable.
(Btw: Its installer tries to put it into your sysdir, but you can move
it into its own directory if preferred.)
http://www.gregorybraun.com/AppPaths.html
There are other frontends for that key, too, sometimes bundled in utilities
with other functionality. One of those, great overall utility with an array
of usages, it's Faber Toys (just noticed its real name now, have erroneously
referred to it as Fabio Toys in the past).
http://www.faberbox.com/
You can launch using a shorcut specifically to the AppPaths function, with
this switch after the faber toys exe name: /ALIAS. This one also is good
for letting you clean up a lot of the unneeded debris that gets written
into that key, making .reg backup files for each of your deletes there.
There is a big trend in installers for them to write prog path names in that
key. It is sometimes only because it was randomly checked by the programmer
when he was running through the wizard checklist on the installer he was
using. Other times it is more deliberate vanity, based on the automatic
presumption that his program will have such prominent role for you that
you will take routine of launching it via its name in the RUN... dialog.
It's only as a very occasional exception that a prog installer writes the
program path in that key for actual important use, such as it needing to
be told about a special path to find its DLLs.
Also, there is one more unusual kind of use. Involves telling stories to
programs that look there when they launch another program. I went through
this area in an involved project once when trying to redirect calls to
regedit, in order to layer a couple of regedit shells, and learnt that
things were very inconsistent, about some programs honoring that key, but
most not even looking there.
(BTW, when I have not ruled out the possibility that a program might have
written an entry to the key for purpose of telling another program a story,
then I don't delete it. Thus in that key I have for instance some MS Office
entries left alone, since I've not verified their role one way or another.)
As to using the AppPaths key for your own customization, for the use
described in the quoted program description, I see that as a much weaker
strategy over using the method of putting .lnks in the path.
The Run... dialog is one of only a very few contexts where the AppPaths
settings have influence for execution. OTOH, an .lnk to a program (or to
a folder or to a document file) that is in your path, it will not only be
executed as a result of typing that name in RUN... dialog -- but as well
in many other contexts. Context of many of the menu utilities, for instance.
And too, hyperlinked functionally in many editors too. Ssome will want a
protocol defined (file
rogram.lnk), but others will even render straight
"program.lnk" as hot and executable.
So that I don't crowd a part of my path that has other primary use (eg
windir or other), I've added a special directory to my path, specifically
for these .lnks.
In NT-based OS, there is a regkey for adding extra directories to your path.
In w98, it is done via autoexec.bat, using the PATH= line. There are a
couple of special rules to follow for going about it there, if wanting to
add a number of directories, but I'll skip off rambling on that.
Another strong advantage to using .lnks over the AppPaths key, it is that
you have much more convenient access to reminding yourself of your available
entries, deleting unused, renaming, making new ones, etc.
Basic conclusion: there is no need to run the VB app mentioned to get the
functionality it described.
