Problems shelling another application
in [Visual Basic]
|
From: Karl E. Peterson on 18 Dec 2009 18:57 Bob Butler formulated on Friday : > "Steve" <sredmyer(a)yahoo.com> wrote ... > On Dec 18, 2:19 pm, Karl E. Peterson <k...(a)exmvps.org> wrote: >> Steve expressed precisely : >> >> I can't imagine why this would matter as I am including the full path >> to the exe in the command line given to the shell function?? > > When you use Start / Run or the command environment to start an app it is > started with current directory set the same as the directory the app is in. That was my suspicion. So the app is just extremely poorly written, in that it's too lazy to "find itself" as it looks for other files that are in the same directory. Lame. Someone needs to give that devteam holy whatfor! -- ..NET: It's About Trust! http://vfred.mvps.org
From: MikeD on 18 Dec 2009 20:59 "Karl E. Peterson" <karl(a)exmvps.org> wrote in message news:Ovsbk3DgKHA.1540(a)TK2MSFTNGP06.phx.gbl... > Bob Butler formulated on Friday : >> "Steve" <sredmyer(a)yahoo.com> wrote ... >> On Dec 18, 2:19 pm, Karl E. Peterson <k...(a)exmvps.org> wrote: >>> Steve expressed precisely : >>> >>> I can't imagine why this would matter as I am including the full path >>> to the exe in the command line given to the shell function?? >> >> When you use Start / Run or the command environment to start an app it is >> started with current directory set the same as the directory the app is >> in. > > That was my suspicion. So the app is just extremely poorly written, in > that it's too lazy to "find itself" as it looks for other files that are > in the same directory. Lame. Someone needs to give that devteam holy > whatfor! > That's what I was thinking too. The app shouldn't "bomb" just because the current directory is not the same as the application directory. IMO, Steve's fix of setting the current directory prior to launching the app isn't really the "right" fix. UNLESS, of course, this app he's launching is not his own and so he doesn't have the source code to fix the problem in it, in which case setting the current directory first may very well be the only work-around to the problem. -- Mike
From: Karl E. Peterson on 18 Dec 2009 21:44 MikeD formulated the question : > > "Karl E. Peterson" <karl(a)exmvps.org> wrote in message > news:Ovsbk3DgKHA.1540(a)TK2MSFTNGP06.phx.gbl... >> Bob Butler formulated on Friday : >>> "Steve" <sredmyer(a)yahoo.com> wrote ... >>> On Dec 18, 2:19 pm, Karl E. Peterson <k...(a)exmvps.org> wrote: >>>> Steve expressed precisely : >>>> >>>> I can't imagine why this would matter as I am including the full path >>>> to the exe in the command line given to the shell function?? >>> >>> When you use Start / Run or the command environment to start an app it is >>> started with current directory set the same as the directory the app is >>> in. >> >> That was my suspicion. So the app is just extremely poorly written, in >> that it's too lazy to "find itself" as it looks for other files that are in >> the same directory. Lame. Someone needs to give that devteam holy >> whatfor! > > That's what I was thinking too. The app shouldn't "bomb" just because the > current directory is not the same as the application directory. IMO, Steve's > fix of setting the current directory prior to launching the app isn't really > the "right" fix. UNLESS, of course, this app he's launching is not his own > and so he doesn't have the source code to fix the problem in it, in which > case setting the current directory first may very well be the only > work-around to the problem. Right. I was also assuming the shelled app wasn't his own, or else he'd have known about this idiotic limitation. There's any number of cases where setting the current directory for stuff like this is necessary, and when working with others' code it's often the best (only) thing you can do. -- ..NET: It's About Trust! http://vfred.mvps.org
From: MikeD on 18 Dec 2009 23:54 "Karl E. Peterson" <karl(a)exmvps.org> wrote in message news:ut9VDVFgKHA.1824(a)TK2MSFTNGP04.phx.gbl... > > Right. I was also assuming the shelled app wasn't his own, or else he'd > have known about this idiotic limitation. There's any number of cases > where setting the current directory for stuff like this is necessary, and > when working with others' code it's often the best (only) thing you can > do. But that still doesn't excuse the problem existing in the shelled app. As you said earlier, "extremely poorly written". -- Mike
From: Dee Earley on 21 Dec 2009 05:48
On 18/12/2009 19:08, Steve wrote: > On Dec 18, 1:54 pm, "Nobody"<nob...(a)nobody.com> wrote: >> "Steve"<sredm...(a)yahoo.com> wrote in message >> >> news:81b5310d-6611-4b95-97ad-2271c2f6c213(a)k4g2000yqb.googlegroups.com... >> >>> Where can I find this app Process Explorer? >> >> Type "Process Explorer" in Google then click "I'm Feeling Lucky!" > > Ok I found and installed Process Explorer and indeed the app is > starting then imediately terminating. > I wonder why this would be? > Again using the exact same string in the Run dialog starts the app as > expected. > I thought that calling shell from VB was essentialy indentical to > launching an app via the Run dialog. Shell uses CreateProcess(). The run dialog uses ShellExecute() which wraps CreateProcess with lots of niceties like path/parameter splitting, URL handling, file verbs, process elevation, etc. -- Dee Earley (dee.earley(a)icode.co.uk) i-Catcher Development Team iCode Systems |