How do I set the PATH variable in VB . Maybe a stupid question.
Are there any other options to run an exe without modifying PATH variable.
Thanks in advance. Regards
Get our unique weekly Newsletter with tips and techniques, how to's and critical updates on Windows 7, Windows 8, Windows XP, Firefox, Internet Explorer, Google, etc. Join our 480,000 subscribers!
+ Get this BONUS — free!
Get the most of Excel! Learn about new features, basics of creating a new spreadsheet and using the infamous Ribbon in the first chapter of Excel 2013: The Missing Manual - Subscribe and download Chapter 1 for free!
What exactly are you trying to do and why do you think you need to set an environmental variable to do it? The executable runs wherever it is. If you want it to reference another file or find something in a particular folder, you handle that internally to the VB program.
I have an executable which can be placed anywhere in the PC . This executable is invoked from another OS (ie unix). Program in unix doesnot understand where the exe is . The effect of this program is as good as what we do in 'Start --> Run' .
Now I did try package and deployment wizard . But the file created by it is very big (12 MB whereas my executable is hardly 400 KB). Further I fear this package & deployment wizard copies system files on development PC to the target PC . I feel this is not required because the exe is simple and have 3 default references + 1 office reference and no components are used.
So I need a way whereby the client PC understands where the exe is . I have an installation program to do this (with other setup criteria and installation path). Now the problem is how do I make system to search this folder for running the exe.
I wish to do things through VB program only.
The reason the setup is large is because it has to include the VB runtime files. Otherwise, your executable will not work on a machine unless that machine already has the runtime files installed. That is the piece that often gets overlooked when people point out how small VB executables are. Yes the wizard does copy libraries to the target system because that's the only way to insure that the program will run on the target machine. If the references don't exist on the target machine and you don't install them with a setup, then your program won't run regardless of what PATH is set.
I'm sorry, but I don't understand how invoking a program from a non-Windows OS can make use of a PATH variable. If you don't have a location for the executable, then how does the other OS invoke it? It sounds like there is something you haven't explained.
The fears for using package and deployment wizard is
1. Size of the file. This precludes the exe to be sent by email / publishing on intranet locations.Further we expect quite frequent maintenance for such exe. So size is very crucial problem.
2. The wizard copies the system files from development PC (where exe is develpoed) to deployment PC (PC where it is run). Now these copied system files may in turn conflict with similar system files in deployment PC . Probably other programs in deployment PC may not run properly due to system files from development PC. This may corrupt (??) deployment PC system files if such PC have different OS (of course of MS windows) and/or different MS office versions. Correct me if wrong.
Now I am invoking exe from a server ERP software (installed on unix). The ERP has some dll function to start any exe on client if the path is known. But if the path differs from client (PC) to client (pc) then single code can not be written in ERP to run an exe.
So my idea is to modify the system environment variable (in windows) PATH at the time of installation of the exe to include the specifc folder of exe in PATH. Then anybody writing exe in START --> RUN (without knowing where this exe is) can successfully run the exe . Same way ERP software can invoke exe successfully for ERP environment .
Further we do not wish to duplicate the exe by copying the sameany other system folder (like c:windows)
You wouldn't want to set the PATH variable on installation only - it would be only for that session; you'd have to modify the registry. Would the following be feasible:
- Create a batch file in a fixed location, e.g. C: or the Windows folder
- The batch file calls your app in its location (which may vary from client to client; the path is written into the batch file on installation)
- Have the ERP software run the batch file (which is in a fixed location)
The packaging wizard does NOT copy system folders. It does copy necessary libraries, etc., and it is possible that installing a setup will break something else. This is also true of installing any other program you might purchase. If you send an exe by email, most email filters will prevent the attachment from coming in unless the recipient is in total denial of the risks of unprotected email. Not to mention the fact that if the target machine doesn't have at least Office 2000 installed, it won't have VB6 runtime files to make the executable work (assuming the exe was written in VB6).
I've only used the PD Wizard twice. The first time, I let it include everything it wanted. The second time, I took out everything but my own code. Both worked equally well. Not sure what this proves, but if you test it in your target environment, you might find that you don't need the entire package because the client PCs already have all the standard stuff from the last thing they installed...
Currently I copy the exe also in windows directory ('windir') . That make the exe run without specifiying the path.However this is duplication and naive way of making things work.
So I plan to do following.
1. to test package wizard without any system files and see wht the size is.
2.My development in VB6 . I have tested my environment and works nicely in office 2002 and 2000. I would check and test the exe in machine with office 97.
3. I will not test batch file with fixed location at this moment because I am sure it will work . But I don't prefer batch file for this purpose.
Your application should work in Officd 2000 and Office XP environments because they are both based on VB6 and the runtime files should already be there. Office 97 was based on VB5, and the VB5 and VB6 runtime files are not interchangeable.