ShellExecute
Depending on what you really want to do, you may not need to go as far as
using ShellExecute. You could simply just use the "Shell" command and pass
the fully qualified path of the CAD file you want to open up:
Dim x as Long
Dim strCADApp as String
Dim strFullyQualifiedCADFile as String
strCADApp = <where ever your CAD applications is located>
strFullyQualifiedCADFile = <Fully Qualified path to CAD File>
x = Shell(strCADApp + " " + FullyQualifiedCADFile)
This bit of code will open the CAD app with your file.
If you would like, I have written a "DLL" that not only launches external
apps with files, but suspends your VB application until you are done with
the other application. Basically, as you launch the application it watches
the process of the application you have launched. Once you close that application,
it sees that the process is now gone from your system. It then releases
your VB application. This is very helpful if you need to do something like
ZIP up a file with an external tool, before you go on in your VB code.
[1138 byte] By [
Steve] at [2007-11-10 0:20:49]
# 1 Re: ShellExecute
Hi Steve,
: Depending on what you really want to do, you may not need to go as far as
: using ShellExecute. You could simply just use the "Shell" command and
pass
: the fully qualified path of the CAD file you want to open up:
:
[snip code]
: This bit of code will open the CAD app with your file.
That certainly is interesting, but is it worth the work?
Consider:
1) You'd have to look up the path for the EXE that you want to open the file
with - no hardcoding here! For this, you'd have to use FindExecutable, go
through HKEY_CLASSES_ROOT with a fine-tooth comb (yuck!) or search the hard
drive(s) and get the path.
2) The program might use DDE to open a file, and AFAIK there's no way of
doing that without messing with DDE calls and the like (which are difficult
to do from VB).
ShellExecute is, in fact, the best solution because it does all of this work
for you. As long as a file is registered to open with an application, it
works.
And there's another benefit of ShellExecute: It honors system and user
policies. Say that you prevent your users from running application XYZ
(through policies), because it has some harmful effects - but administrators
can run it. Files of type .xyz are associated with application XYZ in the
registry.
You design a wrapper program that launches XYZ with a specific .xyz file if
the user is an administrator, and if he's not, you display an error message
and exit.
If you weren't using ShellExecute, you'd have to actually check whether the
user was an administrator and then run the program, and the check could be
fooled. But if you're using ShellExecute, it will detect that you aren't
allowed to run the program and will return an error code, which you can then
display.
Also, if you want to get the "Designed for Windows" logo, then you *have* to
use ShellExecute.
: If you would like, I have written a "DLL" that not only launches external
: apps with files, but suspends your VB application until you are done with
: the other application.
[...]
Again, that is interesting, but it's not really necessary to wrap this up in
a DLL. A class module would be sufficient and would eliminate the
(unnecessary) dependency.
Don't take these comments personally; think of them as just ideas you might
want to take note of.
--
Damit Senanayake | damit@mvps.org
Please reply to newsgroups, not by e-mail.
http://members.xoom.com/damit | {http,ftp}://damit.dyndns.org (experimental)
ICQ: 6930718
# 2 Re: ShellExecute
Hi Steve,
: Depending on what you really want to do, you may not need to go as far as
: using ShellExecute. You could simply just use the "Shell" command and
pass
: the fully qualified path of the CAD file you want to open up:
:
[snip code]
: This bit of code will open the CAD app with your file.
That certainly is interesting, but is it worth the work?
Consider:
1) You'd have to look up the path for the EXE that you want to open the file
with - no hardcoding here! For this, you'd have to use FindExecutable, go
through HKEY_CLASSES_ROOT with a fine-tooth comb (yuck!) or search the hard
drive(s) and get the path.
2) The program might use DDE to open a file, and AFAIK there's no way of
doing that without messing with DDE calls and the like (which are difficult
to do from VB).
ShellExecute is, in fact, the best solution because it does all of this work
for you. As long as a file is registered to open with an application, it
works.
And there's another benefit of ShellExecute: It honors system and user
policies. Say that you prevent your users from running application XYZ
(through policies), because it has some harmful effects - but administrators
can run it. Files of type .xyz are associated with application XYZ in the
registry.
You design a wrapper program that launches XYZ with a specific .xyz file if
the user is an administrator, and if he's not, you display an error message
and exit.
If you weren't using ShellExecute, you'd have to actually check whether the
user was an administrator and then run the program, and the check could be
fooled. But if you're using ShellExecute, it will detect that you aren't
allowed to run the program and will return an error code, which you can then
display.
Also, if you want to get the "Designed for Windows" logo, then you *have* to
use ShellExecute.
: If you would like, I have written a "DLL" that not only launches external
: apps with files, but suspends your VB application until you are done with
: the other application.
[...]
Again, that is interesting, but it's not really necessary to wrap this up in
a DLL. A class module would be sufficient and would eliminate the
(unnecessary) dependency.
Don't take these comments personally; think of them as just ideas you might
want to take note of.
--
Damit Senanayake | damit@mvps.org
Please reply to newsgroups, not by e-mail.
http://members.xoom.com/damit | {http,ftp}://damit.dyndns.org (experimental)
ICQ: 6930718
