set working dir for app launched by shell from VB 2

[MargaretK]

I'm working on a VB menu app, trying to launch a SQLWINDOWS app that resides on a network.

I need to specify the default directory (working directory) for the started application. I'm wondering if I need something like an API call, such as CreateProcess. SHELL doesn't seem to have a parameter for this.

Here's the problem:
The menu launches the SQLWINDOWS app with this command:
ld_RetCd = Shell(ls_AppPath & ls_AppId & ".exe" & " " & ls_AppCmdLine, vbNormalFocus)

ls_AppPath is a UNC path and ls_AppId is the name of the executable file.

This commands appears to find the application in the correct directory (ls_AppPath), and try to run it. It fails because the started app cannot find SQLRUN50.EXE that it needs to run. SQLRUN.EXE is located in the same directory as the started application (in ls_AppPath).

I think the started app inherits the current working directory (which I don't want!). I've tried a CHDIR ls_AppPath immediately before the Shell command, but that does not correct the problem.

The application was originally using relative paths for the CHDIR and SHELL commands, but only worked occasionally. It usually failed on the CHDIR command, although the relative path was correct. We switched to UNC path names, which got us past the CHDIR to the SHELL command.

Any ideas?

Thanks!!

 

[Snaggs]

Why not use App.Path in the in the program that is in ls_AppPath? Then the application would know where to find SQLRUN.EXE. If I understand correctly, Program1 is called from an application and Program1 needs to call SQLRUN.EXE. If this is the case, then use App.Path in Program1 so it knows where to find SQLRUN.EXE. In your Program1, you would have SHELL App.Path & "\SQLRUN.EXE".

That should do it for you. Just use the same logic in the shelled application. You had it figured out, you just didn't know it. Snaggs
tribesaddict@swbell.net

 

[MargaretK]

Thanks very much for your help. I really appreciate your taking the time to review my problem. I discovered just a few hours ago what was causing the problem. I am posting it for those of you on a network, because others developing on a network may find it useful.

When developing a VB project on a network drive, and your VB development environment is installed on your hard drive, your current directory will be different depending on how you open the VB development environment.
- If you open VB (START, PROGRAMS, VISUAL BASIC 6.0), and then open your application project from within VB, your current directory when debugging your app will be your VB environment's directory (mine is C:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\VB98). Basically, your application inherits VB's working directory.
- If you open windows explorer and click on your project, which then automatically opens the Visual Basic development environment and displays your application, your working directory when debugging your app will be the directory in which your application resides. (mine is something like S:\test\VBAPPS)

Many app's don't have a problem, because they specifically append the app.path to the file name whenever they read a file, so the working directory is irrelevant. The functions for file handling appear to work OK with UNC path names. Unless you are launching other applications, or doing some other special work, you may not notice this problem.

My area has examples of both situations:
- we have an application which works when opened from within VB development environment, but not when we click on the project file to open VB.
- we have an application which works when we click on the project file to open VB, but does not work when we first open the VB development environment and then open the project file.

Opening the project from within the Visual Basic environment, and defaulting to the working directory on C: offers a unique problem, if you need to change your working directory to a network directory within your application...

If your current working drive is C:, and App.Path returns a UNC (Universal Naming Convention) name for your network drive, you cannot use either CHDIR or CHDRIVE in combination with the App.Path to get to the network drive where your application and all of it's files are stored. You don't know what drive it is on. Although there are API functions which return the UNC name when given a drive name, there is no function to find a drive name corresponding to a UNC name (there are good reasons for this). You must hardcode your drive name either in your application or in an INI file. One article suggested actually mapping a drive to your UNC name, and then using a CHDRIVE to the new drive, but that is not a good solution for many, many reasons. You may have relative paths which need to "back out" a few directories, your user may not want new drives mapped on his/her machine, there may not be new drives available for mapping, and there are many other reasons.

Here are a few facts that are related to setting your working directory to a network drive in VB:
- in the development environment, if a project was loaded from a network share, specified by either a UNC path or a mapped drive path, then App.Path will return a UNC path (I.E. "\\SERV-T2\TIS\010486\TEST&quot when the project is run. This is posted on the Microsoft web page as a "problem".
- CHDRIVE cannot handle UNC paths and will raise an error when App.Path returns a UNC path, so you cannot use the command CHDRIVE App.Path to change your current working directory.
- CHDIR does not handle UNC commands. If you start with your working directory on C:, and use the command CHDIR App.Path, and App.Path returns a UNC name, CHDIR will not raise an error, but the directory will NOT be changed.
- When you launch an application from within VB, using the SHELL command, the application inherits your current working directory. If you have a working directory of C:, and you start program s:\test\myapp.exe, the launched program is found, but it may look for related runtime executables, ini's etc. on the C: drive, and abend.
- When you use the API CREATEPROCESS command to launch a program, although this command allows a parameter for working directory, it will ignore a UNC path name, and inherit the calling program's working directory.

Please note this is a problem mostly related to developing. The apps work OK when installed, because they are executed from the directory where they reside, so this becomes their working directory. The app I had a problem with ran in production, but was getting errors in test, because I opened it in VB, and defaulted to a working directory on the C: drive.

PS:
Tek-Tips is great. Keep up the good work.

 

[Snaggs]

Margaret,

Thanks for following up with the solution. I fell for the CWD (Current Working Directory) issue a few years ago. We had an application that looked in the CWD for the config file. YIKES! Depending on where I started the application depended on what configuration file the program used. Finally someone raised the question why a bug could not be reproduced from day to day without changing a thing. At that point I mentioned what you just explained above. The immediate answer was &quot;We need to fix that now&quot;. Funny when I mentioned it 6 months prior to that, it was no big deal. <grin>. Snaggs
tribesaddict@swbell.net

 

[MargaretK]

I am not alone! Thanks for the help. I read your other post as well. My problem was that since this is a menu, it had to work with the SQLWINDOWS apps that it calls as they exist now, because there are so many of them. For that reason, I also got to explore the world of Global Atomic Tables last week.

I think Microsoft still has some work to do on working directories, and they've barely gotten started on UNC. Every VB project that I work on, I discover at least one bug in VB itself. On my last project, it was the command to show Help. I and the Microsoft Knowledge Base are becoming fast friends




Margaret Knapp
Visual Basic Programmer