set path=MyNewPath;%path%

you can create this batch-file within VB, but it will execute in a DOS-Box.
--
   __
  |_
  | RANK MAHLER

Your directory gets put in the front, knocking existing directories off
the end. Also, some people have a SET PATH= statement in their
*config.sys*, and if it's longer than 122 chars, then you've just
messed up their path more.

One possible solution to these dilemmas:

If you run that batch file, it will load another instance of command.com,
with it's own environment space, which is destroyed when it exits. The
user doesn't notice a thing, and their path doesn't get messed up. The
optimal solution. :)

Bottom line, make it a priority that your app doesn't have to be in the
path, and if it really, really, absolutely, just has to be there, put in
an option to let the user update his/her startup files manually.
--
_________________________________________________________
Robert Woodcock | Note: Your standard disclaimers apply. |

................| it can be quite a curse) - Plucky Duck |

:         set path=MyNewPath;%path%

: you can create this batch-file within VB, but it will execute in a DOS-Box.

... and if you invoke this two line batch file from Windows, either
directly, or via a VB program, the modified path will belong to the
instance of COMMAND.COM created to run the batch file, and will disappear
on completion. It is possible for a DOS program to modify the environment
of its parent process (requires some slight of hand techniques in
assembler). It is not recognized as legal to do this, however, and I
would expect the results to be less predictable with Windows present.

--

EDMONTON, Alberta, CANADA