Problems shelling another application
in [Visual Basic]
|
From: Karl E. Peterson on 18 Dec 2009 14:20 Ralph pretended : > "Karl E. Peterson" <karl(a)exmvps.org> wrote in message > news:u$EAV8AgKHA.2184(a)TK2MSFTNGP04.phx.gbl... >> Steve explained on 12/18/2009 : >>> The code to launch the other app is just a simple >>> shell call (lngProcID = Shell(strAppPath)). The call to Shell does >>> return a value but the app does not appear to have been started (does >>> not show up visually and is not in task manager). >> >> What's the returned value? (If it's between 0-32, that indicates >> failure.) > > Those failures are usually caught by the VB Error Handler. Thus - you have > an error before you can check the return. Might just as well read the > Err.Number. <g> True, but I'll take refuge in your use of "usually" to retort. <g> -- ..NET: It's About Trust! http://vfred.mvps.org
From: Steve on 18 Dec 2009 14:40 On Dec 18, 2:19 pm, Karl E. Peterson <k...(a)exmvps.org> wrote: > Steve expressed precisely : > > > > > > > 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. > > > ????? > > I'm not aware of too many differences. No idea what the curdir is when > you use Start-Run, are you? That could be one thing, if the app is > extremely inflexible in that regard. > > -- > .NET: It's About Trust!http://vfred.mvps.org- Hide quoted text - > > - Show quoted text - DING DINGI DING DING!!! We have a winner. That was it...I set the current directory prior to calling the shell function and now it works as expected. 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?? Oh well it works. Thanks Karl Steve
From: Nobody on 18 Dec 2009 15:02 If you have command line options, and the EXE file name has spaces, you need to surround the EXE path with double-quotes, followed by space then the command line. Sometimes the OS could guess for you where the filename ends and the command line begins, but that may not produce the expected result. Add to that this guessing behavior seems to have been disabled in Vista+, so always use double-quotes around the EXE full path, even if it doesn't contain spaces. See CreateProcess() to see how the OS guesses the path. "Steve" <sredmyer(a)yahoo.com> wrote in message news:deeebad0-41c7-48f2-af83-997ae48223e8(a)m38g2000yqd.googlegroups.com... DING DINGI DING DING!!! We have a winner. That was it...I set the current directory prior to calling the shell function and now it works as expected. 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?? Oh well it works. Thanks Karl Steve
From: Bob Butler on 18 Dec 2009 15:16 "Steve" <sredmyer(a)yahoo.com> wrote in message news:deeebad0-41c7-48f2-af83-997ae48223e8(a)m38g2000yqd.googlegroups.com... 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. When you use the VB Shell function it starts the app in the same current directory as the VB application.
From: Ralph on 18 Dec 2009 15:33 "Karl E. Peterson" <karl(a)exmvps.org> wrote in message news:OfqXrcBgKHA.6096(a)TK2MSFTNGP02.phx.gbl... > Ralph pretended : > > "Karl E. Peterson" <karl(a)exmvps.org> wrote in message > > news:u$EAV8AgKHA.2184(a)TK2MSFTNGP04.phx.gbl... > >> Steve explained on 12/18/2009 : > >>> The code to launch the other app is just a simple > >>> shell call (lngProcID = Shell(strAppPath)). The call to Shell does > >>> return a value but the app does not appear to have been started (does > >>> not show up visually and is not in task manager). > >> > >> What's the returned value? (If it's between 0-32, that indicates > >> failure.) > > > > Those failures are usually caught by the VB Error Handler. Thus - you have > > an error before you can check the return. Might just as well read the > > Err.Number. <g> > > True, but I'll take refuge in your use of "usually" to retort. <g> > Play with these ... On Error GoTo Click_Error ' will silently run - but nothing happens lRtn = Shell(Environ("comspec") & " /c " & "junk.txt") ' will report a valid ProcessID ' similar to the OP's situation Debug.Print lRtn Dim strAppPath As String: strAppPath = "C:\Junk.txt" ' will throw an Error lRtn = Shell("""" & strAppPath & """") Exit Sub Click_Error: Debug.Print Err.Number ' prints 5 Debug.Print lRtn ' prints another valid ProcessID
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Unix timestamp to VB Date Next: WebBrowser Control KeyPreview |