Announcement

Collapse
No announcement yet.

Trouble using PB( SHELL Command

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Marco Pontello
    replied
    Nice! Glad it helped!

    Bye!

    Leave a comment:


  • Trento Castricone
    replied
    Not one to give up, I went back and re-read all the comments in this thread.

    The one I missed was Marco Pontello's.

    "SHELL "ImageFile.exe " & $DQ & strFileName1 & $DQ, 1"
    "Or the spaces in it"

    Works . . .
    I made a path to a picture 226 characters long - no problem.

    Thanks for everyone's input.

    Leave a comment:


  • Michael Mattias
    replied
    Better still..

    Code:
     SHELL  "programIwrotewhichreportsthecontentsof_COMMAND$.exe " & strFileName1,1
    Then you will KNOW what the target EXE sees.

    Leave a comment:


  • Dave Biggs
    replied
    Cliff,
    Thanks for posting the link to Disable 8.3 Naming Convention in XP Something like that may be at work on Trento's system affecting some folders, though I see he now thinks that is not related to his problem.

    Trento,
    Looking at the first post again and thinking about your comment that the problem is related to the length of the parameter passed. I wonder if the VB app itself is choking on the command line, calling the API internally with an invalid parameter and that is where the error is being flagged?

    Certainly a couple of the posts show error message boxes with "ImageFile" in the tiltle bar.

    Perhaps a quick check would be to use
    Code:
    SHELL "MSPaint.exe " & strFileName1, 1

    Leave a comment:


  • Cliff Nichols
    replied
    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.

    Leave a comment:


  • Michael Mattias
    replied
    Would you believe I was testing you?

    I didn't think so.

    My bad.

    MCM

    Leave a comment:


  • Trento Castricone
    replied
    For those coming along later !

    Code:
    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.

    Leave a comment:


  • Michael Mattias
    replied
    >Please beleive me - there is NO "GetLastError".

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

    Eg this...
    Code:
    pid = ShellExecute (0, "open", ShellString, ParamToPic , "", %SW_SHOW)
    ....needs to be changed to eliminate the string literal parameters, as in ..
    Code:
    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...
    Code:
      hProcess               = OpenProcess (pid&, %SYNCHRONIZE, %FALSE) 
      WaitForSingleObject   hProcess, %INFINITE
      CloseHandle              hProcess
    MCM

    Leave a comment:


  • Trento Castricone
    replied
    First, Thanks for all the replies.

    Code:
    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:

    Leave a comment:


  • Cliff Nichols
    replied
    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.

    Leave a comment:


  • Dave Biggs
    replied
    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.

    Leave a comment:


  • Cliff Nichols
    replied
    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.

    Leave a comment:


  • Dave Biggs
    replied
    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.
    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
    Code:
    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.

    Leave a comment:


  • Cliff Nichols
    replied
    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)
    Code:
    #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
    Code:
    #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)

    Leave a comment:


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

    Leave a comment:


  • Michael Mattias
    replied
    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

    Leave a comment:


  • Marco Pontello
    replied
    Originally posted by Trento Castricone View Post
    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!

    Leave a comment:


  • Trento Castricone
    replied
    A little bit more information:

    Code:
    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.

    Leave a comment:


  • Marco Pontello
    replied
    Just a tought:

    Code:
    SHELL "ImageFile.exe " & $DQ & strFileName1 & $DQ, 1
    Bye!

    Leave a comment:


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

    Leave a comment:

Working...
X