Trouble using PB( SHELL Command

[Trento Castricone]

I am trying to SHELL a jpg file to a VB6 program.
Every thing works just fine if the path is short with no spaces.
I create a shortpath for the target jpg.

SetShortPath
SHELL "ImageFile.exe " & strFileName1, 1
 
SUB SetShortPath()
  LOCAL szShortPath AS ASCIIZ * 255
  LOCAL szLongPath  AS ASCIIZ * 255
  szLongPath = SPACE$(255)
  szLongPath = strFileName1
  GetShortPathName szLongPath, szShortPath, SIZEOF(szShortPath)
  strFileName1 = szShortPath
END SUB

[ I still get the error even if I physically remove all the spaces from the path. ]

[Michael Mattias]

>SHELL "ImageFile.exe " & strFileName1, 1

At this point the system ERR variable reports.... ??????

[Trento Castricone]

Mike

Yes, I get the run-time error at the execution of the shell statement

[Michael Mattias]

>Yes, I get the run-time error at the execution of the shell statement

Do we get a hint? May we buy a vowel?

Or did testing ERR solve your problem by pinpointing the problem?

[Trento Castricone]

There is no err error !
The error I get is in the original post.
[ run-time error ]

[Marco Pontello]

Just a tought:

SHELL "ImageFile.exe " & $DQ & strFileName1 & $DQ, 1

Bye!

[Trento Castricone]

A little bit more information:

ShellString = "ImageFile.exe"
ShellExecute 0, "open", ShellString, strFileName1 & " ", "", %SW_SHOW

Using SHELLEXECUTE works the same as SHELL.

It definitly has to do with the lenght of the string.

[Marco Pontello]

It definitly has to do with the lenght of the string.

Or the spaces in it. Have you already tried the fragment I posted?

Bye!

[Michael Mattias]

Your first picture (snap3) shows a bad short file name. Only part of it ("TRENT0~1" ) is converted to 8.3 format. Check the return from GetShortPathName, something is wrong here.

Snap2 says the system could not file that file, which is not a surprise based on the above

>I still get the error even if I physically remove all the spaces from the path. ]

If snap3 is showing the file name AS YOU EDITED IT (code not shown)......

The file name itself "Susquehannock" contains more than 8 characters, meaning its not an 8.3 short name. Since you did nothing about that, have to believe Windows is gettting lost because part of the file name is long form and part of it is short form.

MCM

[Trento Castricone]

Using Dir/x in a dos window to show shortpaths.
Notice that after the desktop the shortpaths STOP.

[Cliff Nichols]

There is no err error !
The error I get is in the original post.
[ run-time error ]

Ok I had to bite, seeing how I too used to use VB and recognized the error.

By the way before I post the reasons why to post compilable code, does anyone want to make a bet that the file in question is not passed with the file-type?, or invalid path of other sorts? (seeing how my sadomasochist attitude made me do this in the 1st place on halloween of all nights?)

While I was coming up with this, some other posts were made that I will leave my best guess to last

1.) Original Post

#COMPILE EXE
#DIM ALL
#INCLUDE "Win32Api.inc"

GLOBAL strFileName1 AS STRING
FUNCTION PBMAIN () AS LONG
strFileName1 = "C:\Users\Public\Pictures\Sample Pictures\Creek"
SetShortPath
SHELL "ImageFile.exe " & strFileName1, 1


END FUNCTION

SUB SetShortPath()
LOCAL szShortPath AS ASCIIZ * 255
LOCAL szLongPath AS ASCIIZ * 255
szLongPath = SPACE$(255)
szLongPath = strFileName1
GetShortPathName szLongPath, szShortPath, SIZEOF(szShortPath)
strFileName1 = szShortPath
MSGBOX "Long Path = " + $CR + szLongPath + "Short Path = " + $CR + szShortPath + "Resulting Path = " + $CR + strFileName1
END SUB

Not compilable of course, so 1 copy , 2 clicks to create a demo default compilable, and 1 paste later. (plus time to comment)

#COMPILE EXE
#DIM ALL
#INCLUDE "Win32Api.inc"

GLOBAL  strFileName1 AS STRING
FUNCTION PBMAIN () AS LONG
strFileName1 = "C:\Users\Public\Pictures\Sample Pictures\Creek"
SetShortPath
SHELL "ImageFile.exe " & strFileName1, 1
    

END FUNCTION

SUB SetShortPath()
  LOCAL szShortPath AS ASCIIZ * 255
  LOCAL szLongPath  AS ASCIIZ * 255
  szLongPath = SPACE$(255)
  szLongPath = strFileName1
  GetShortPathName szLongPath, szShortPath, SIZEOF(szShortPath)
  strFileName1 = szShortPath
MSGBOX "Long Path = " + $CR + szLongPath + "Short Path = " + $CR + szShortPath + "Resulting Path = " + $CR + strFileName1
END SUB

Oh and I had to make a global to compile. But still no usable results, more spaghetti code

Then cleaning up and making it work

#COMPILE EXE                                                          'Added to make compile
#DIM ALL                                                              'Added to make compile
#INCLUDE "Win32Api.inc"                                               'Added to make compile

FUNCTION PBMAIN () AS LONG                                            'Added to make compile
LOCAL strFileName1 AS ASCIIZ * %MAX_PATH                              '<--- Had to guess at String, but 1st guess was wrong
'strFileName1 = "C:\Users\Public\Pictures\Sample Pictures\Creek"       '<--- Change to a file you have on your system, I had to guess since none chosen
strFileName1 = "C:\Users\Public\Pictures\Sample Pictures\Creek.jpg"   '<--- 1st test I forgot the .jpg and caused problems
'strFileName1 = "C:\Users\Public\Pictures\Sample_Pictures\Creek"       '<--- Change to a file you have on your system, I had to guess since none chosen
SetShortPath strFileName1                                             '<--- Get the Short-Path version
SHELL "ImageFile.exe " & strFileName1, 1                              'Shell the file to image (No clue how this gets to VB)
'*** Then Again...what is ImageFile.exe??? not something on my system??? so is it the VB.EXE that you are/have created?
END FUNCTION

'SUB SetShortPath()
FUNCTION SetShortPath(PathToGet AS ASCIIZ * %MAX_PATH)AS STRING       'Changed to function with parameter so it works
'  LOCAL szShortPath AS ASCIIZ * 255
  LOCAL szShortPath AS ASCIIZ * %MAX_PATH                             'I hate Hard-Coded values rather than equates
'  LOCAL szLongPath  AS ASCIIZ * 255
  LOCAL szLongPath AS ASCIIZ * %MAX_PATH                              'I hate Hard-Coded values rather than equates
     LOCAL LastError AS LONG                                          'My Error Handling
     LOCAL ErrorBuff AS ASCIIZ * %MAX_PATH                            'My Error Handling
     LOCAL Result AS LONG                                             'My Error Handling
  szLongPath = SPACE$(255)
'  szLongPath = strFileName1                            'First version I had to make global to make work, but no file was chosen
  szLongPath = PathToGet                               'Corrected version for this demo
'*** 1st couple of tries I added a lil bit of error handling, and discovered my 1st test left the filetype off the path
  Result = GetShortPathName(szLongPath, szShortPath, SIZEOF(szShortPath))       'Changed to use 'My Error Handling
     LastError = GetLastError                                         'My Error Handling
     FormatMessage %FORMAT_MESSAGE_FROM_SYSTEM, BYVAL %NULL, LastError, %NULL, ErrorBuff, SIZEOF(ErrorBuff), BYVAL %NULL     'Format the message      'My Error Handling
     IF Result = %ERROR_INVALID_PARAMETER THEN MSGBOX "Read the DOCS....Your error is explained in Win32 Programmers reference"        'My Error Handling
MSGBOX "Results = " + STR$(Result) + $CR + "Error = " +  ErrorBuff
'  strFileName1 = szShortPath
  PathToGet = szShortPath                               'Again corrected version
MSGBOX "Long Path = " + szLongPath + $CR + "Short Path = " + szShortPath             'Hey NOW IT WORKS and others can see what I did to find it
END FUNCTION
'END SUB

Now at least I see the long and short file names.

Now Trento, you see why MCM asked about the error values, and I know someone else asked about compilable code, because, "If we do not see what you are doing, line by line, then we can be WAYYYY off and guessing directions in the midst of a snowstorm on Mt Washington and pass relief by "Only a few steps")

That said, and one of your posts while I was posting...I will bet a dime to a dollar that your path is over 67 bytes, and my messagebox will tell you so.

(Change the file path to whatever your file is, I just chose a random JPG file)

[Dave Biggs]

Trento,

There is something odd in the screen shot of the DOS box, even before you change the directory. The 'Splash Screen' DIR/x listing should look like
DIR> SPLASH~1 Splash Screen - shouldn't it?

Could there be a problem with your PC? Did you re-boot recently?


Cliff,

What's wrong with a path length > 67?

That said, and one of your posts while I was posting...I will bet a dime to a dollar that your path is over 67 bytes, and my messagebox will tell you so

The ANSI version of GetShortPathName can take long form path strings up to MAX_PATH.

I plugged this into your test code.

strFileName1 = "C:\Documents and Settings\Default User\Application Data\Microsoft\Internet Explorer\Splash Screen\Technical Notification SW 221_Rev_A.pdf"

And it was fine - first message box indicated a returned length of 69.
Second message box gave the result as

Short Path = C:\DOCUME~1\DEFAUL~1\APPLIC~1\MICROS~1\INTERN~1\SPLASH~1\TECHNI~1.PDF

I think your and MCM's suggestion that calls to the API should be checked for any errors returned is a good one but there may be something else going on with Trento's system. See the DOS box screen shot that he posted.

[Cliff Nichols]

Dave,
>>>What's wrong with a path length > 67?.....welllll According to my docs

Remarks

When an application calls this function and specifies a path on a volume that does not support 8.3 aliases, the function fails with ERROR_INVALID_PARAMETER if the path is longer than 67 bytes.

[Dave Biggs]

Thanks Cliff, I hadn't read that far

I don't think that will be the issue here though. "..volume that does not support 8.3 aliases.." - that would be MS-DOS FAT ?? Not what Trento has judging by the screen shots.

[Cliff Nichols]

I am trying to think of a better example (maybe a thumbdrive or similar device but....) If a person knows about 8.3 conventions and have disabled the ability in their system, then my post above would hold true

For example http://www.rchamp.com/2007/09/05/dis...vention-in-xp/

Anyways, its just a train of thought that should be considered when not knowing what the cause of the problem may be.

[Trento Castricone]

First, Thanks for all the replies.

LOCAL ShellString AS ASCIIZ * %MAX_PATH
LOCAL ParamToPic AS ASCIIZ * %MAX_PATH
 
pid = ShellExecute (0, "open", ShellString, ParamToPic , "", %SW_SHOW)

PB9's SHELL works as advertised with the parameter length less than 99 in WinXP and 97 in Vista Home Premium.
The same is true of the SHELLEXECUTE API.

Both of my systems generate short paths, but NOT all folders have a short paths. ( as shown in my post above using the "DIR/X" command.)
Turns out this is NOT relevent to the problem.

The problem comes down to the length of the parameter passed.
( In this case "ParamToPic" )

Please beleive me - there is NO "GetLastError".
The error is:

[Michael Mattias]

>Please beleive me - there is NO "GetLastError".

There never will be if you use string literals in the "call of interest. "

Eg this...

pid = ShellExecute (0, "open", ShellString, ParamToPic , "", %SW_SHOW)

....needs to be changed to eliminate the string literal parameters, as in ..

szVerb = "open"
pid = ShellExecute (0, szVerb, ShellString, ParamToPic , BYVAL %NULL, %SW_SHOW)
LE  = GetLastError()

FWIW, if you now want to emulate the SHELL (statement) behavior by suspending your process until the child process has completed...

  hProcess               = OpenProcess (pid&, %SYNCHRONIZE, %FALSE) 
  WaitForSingleObject   hProcess, %INFINITE
  CloseHandle              hProcess

MCM

[Trento Castricone]

For those coming along later !

hProcess = OpenProcess (%SYNCHRONIZE, %FALSE,Pid1)
WaitForSingleObject   hProcess, %INFINITE
CloseHandle           hProcess

The parameters for the "OpenProcess" API are backwards in your post above.

I appreciate all your help.

[Michael Mattias]

Would you believe I was testing you?

I didn't think so.

My bad.

MCM

[Cliff Nichols]

I saw the same error code (or one close to it) while working on my error handler

Could be a koinky-dink or an actual, but if memory serves, then the file in question could not only not be found, but does not exist at all as far as the computer and the registry is concerned.