Shell (start xxxxx) not working for full Windows-path directory files (works for 8-character directory paths) 
Author Message
 Shell (start xxxxx) not working for full Windows-path directory files (works for 8-character directory paths)

Thanks Rick - incredible!


Quote:
> The Shell command works fine with long file names. The problem is there is
a
> blank space in the path and/or filename. DOS uses blank spaces as
> delimiters. The way to hide the blank space from DOS is to enclose the
> combined path/filename in quote marks like so

> Say your path filename was C:\Program Files\My Program.exe. Instead of
using

>      Shell "Start C:\Program Files\My Program.exe"

> use this instead

>      Shell "Start ""C:\Program Files\My Program.exe"""

> That will insure that DOS receives the path/filename enclosed in quote
> marks. If you have the path/filename stored in a variable, say

>      FileToRun = "C:\Program Files\My Program.exe"

> then your Shell statement would look like this

>      Shell "Start """ & FileToRun & """"

> Obviously, the Shell arguments can be quite varied, but the principle is
the
> same, *each* path/filename containing blank spaces in it *must* be passed
> enclosed in its own quote marks. You can always use the extra quote marks
as
> (shown above) even if the path/filename does not have a blank space in
it --
> it doesn't hurt to provide them.

> Rick



> > I have a smallish problem(!!).
> > I want to run processes using the SHELL (Start ... ) command inside my
> > application.
> > This is fine as long as the application is on a path that conforms to
> > DOS-file naming convetion standards (i.e. 8 characters).
> > It doesnt seem to be able to find the full path file when any of the
> > directory names ae outside that length (e.g C:/Program Files/ needs to
be
> > used as C:/PROGRA~1/ ). The only thing is, I offer the user a common
> dialog
> > box to allow them to select a file. This will then return the full
Windows
> > path with the file (or in some cases I use App.Path + Filename), so if
the
> > choose a file in a directory that just happens to conform to the
> 8-character
> > rule, it works fine, otherwise, it just does nothing. The funny things
is,
> > the Dir(...) command (to see if the file exists) on the same value works
> > fine!
> > So....
> > Question is, how do I get or change the DOS path for the Windows Path
> > returned from the commondialog box?
> > Help....
> > Thanks, Paul.



Wed, 18 Jun 1902 08:00:00 GMT  
 Shell (start xxxxx) not working for full Windows-path directory files (works for 8-character directory paths)

Thanks Rick.  Incredible knowledge!


Quote:
> The Shell command works fine with long file names. The problem is there is
a
> blank space in the path and/or filename. DOS uses blank spaces as
> delimiters. The way to hide the blank space from DOS is to enclose the
> combined path/filename in quote marks like so

> Say your path filename was C:\Program Files\My Program.exe. Instead of
using

>      Shell "Start C:\Program Files\My Program.exe"

> use this instead

>      Shell "Start ""C:\Program Files\My Program.exe"""

> That will insure that DOS receives the path/filename enclosed in quote
> marks. If you have the path/filename stored in a variable, say

>      FileToRun = "C:\Program Files\My Program.exe"

> then your Shell statement would look like this

>      Shell "Start """ & FileToRun & """"

> Obviously, the Shell arguments can be quite varied, but the principle is
the
> same, *each* path/filename containing blank spaces in it *must* be passed
> enclosed in its own quote marks. You can always use the extra quote marks
as
> (shown above) even if the path/filename does not have a blank space in
it --
> it doesn't hurt to provide them.

> Rick



> > I have a smallish problem(!!).
> > I want to run processes using the SHELL (Start ... ) command inside my
> > application.
> > This is fine as long as the application is on a path that conforms to
> > DOS-file naming convetion standards (i.e. 8 characters).
> > It doesnt seem to be able to find the full path file when any of the
> > directory names ae outside that length (e.g C:/Program Files/ needs to
be
> > used as C:/PROGRA~1/ ). The only thing is, I offer the user a common
> dialog
> > box to allow them to select a file. This will then return the full
Windows
> > path with the file (or in some cases I use App.Path + Filename), so if
the
> > choose a file in a directory that just happens to conform to the
> 8-character
> > rule, it works fine, otherwise, it just does nothing. The funny things
is,
> > the Dir(...) command (to see if the file exists) on the same value works
> > fine!
> > So....
> > Question is, how do I get or change the DOS path for the Windows Path
> > returned from the commondialog box?
> > Help....
> > Thanks, Paul.



Wed, 18 Jun 1902 08:00:00 GMT  
 Shell (start xxxxx) not working for full Windows-path directory files (works for 8-character directory paths)

Thanks Rick.  Incredible knowledge!


Quote:
> The Shell command works fine with long file names. The problem is there is
a
> blank space in the path and/or filename. DOS uses blank spaces as
> delimiters. The way to hide the blank space from DOS is to enclose the
> combined path/filename in quote marks like so

> Say your path filename was C:\Program Files\My Program.exe. Instead of
using

>      Shell "Start C:\Program Files\My Program.exe"

> use this instead

>      Shell "Start ""C:\Program Files\My Program.exe"""

> That will insure that DOS receives the path/filename enclosed in quote
> marks. If you have the path/filename stored in a variable, say

>      FileToRun = "C:\Program Files\My Program.exe"

> then your Shell statement would look like this

>      Shell "Start """ & FileToRun & """"

> Obviously, the Shell arguments can be quite varied, but the principle is
the
> same, *each* path/filename containing blank spaces in it *must* be passed
> enclosed in its own quote marks. You can always use the extra quote marks
as
> (shown above) even if the path/filename does not have a blank space in
it --
> it doesn't hurt to provide them.

> Rick



> > I have a smallish problem(!!).
> > I want to run processes using the SHELL (Start ... ) command inside my
> > application.
> > This is fine as long as the application is on a path that conforms to
> > DOS-file naming convetion standards (i.e. 8 characters).
> > It doesnt seem to be able to find the full path file when any of the
> > directory names ae outside that length (e.g C:/Program Files/ needs to
be
> > used as C:/PROGRA~1/ ). The only thing is, I offer the user a common
> dialog
> > box to allow them to select a file. This will then return the full
Windows
> > path with the file (or in some cases I use App.Path + Filename), so if
the
> > choose a file in a directory that just happens to conform to the
> 8-character
> > rule, it works fine, otherwise, it just does nothing. The funny things
is,
> > the Dir(...) command (to see if the file exists) on the same value works
> > fine!
> > So....
> > Question is, how do I get or change the DOS path for the Windows Path
> > returned from the commondialog box?
> > Help....
> > Thanks, Paul.



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. shell command with space in path/file name does not work

2. shell command with space in path/file name does not work

3. ExtCreatePen does not work in Windows 2000 but works in Windows 98

4. How to find Directory from Full File path

5. How to find Directory from Full File path

6. shell command and working directory

7. Help me extract full EXE path from Windows GRP file

8. Setting working directories for apps launched with SHELL

9. Specify working directory for shell.run command?

10. access db not working passing from windows 98 to windows Me

11. Getting full list of Domain Users is not working properly - some users missing

12. it's work with windows NT not with Windows 95

 

 
Powered by phpBB® Forum Software