Share via

Something Missing... Reference?

Anonymous
2015-04-18T11:33:00+00:00

Using Windows 8 with Office Home and Business 2010 (Version 14.0.7147.5001)

Using Visual Basic in Excel

References:

Visual Basic for Applications

Microsoft Excel 14.0 Object Library

Microsoft Office 14.0 Object Library

Microsoft Word 14.0 Object Library

Microsoft Shell controls and Automation

Microsoft Forms 2.0 Object Library

OLE Automation

Programing originally written in Windows 95 Visual Basic was successfully converted to Windows XL. The conversion to Windows 8 results in

the error message:    "Run time error 5      Invalid procedure call or argument" from the following line of code:

AciApp = Shell("C:\ACI32\Applications\Report32.EXE", 1)

Looking for some help

Thanks

Microsoft 365 and Office | Excel | For home | Windows

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments No comments

Answer accepted by question author

Anonymous
2015-04-18T20:41:56+00:00

Thank you. Yes, this command does start the application. It takes longer than normal to open the application and it does not appear to have focus when it opens. Is there a "Wait" option in this structure?  

The following is a compilation of several posts I've given in the past regarding the Shell command. The lead-in stuff may help you understand how to work with Shell in general, but the question you are now asking is addressed toward the bottom (starts with the paragraph I made bold).

You can use the Shell command. To execute internal DOS command (Dir, Copy, etc. as well as redirection of screen output), the command processor must be specified (using the Environ$ function and "comspec" as its argument returns the correct command processor path on NT and non-NT systems) . Specifying the command processor is safe & generic and will work with non-internal commands also. That syntax, using an XCopy command as an example is:

Shell  Environ$("comspec") & " /c xcopy """ & _

         Source & """ """ & Destination & """ " & Option, vbHide

You set the Source and Destination (string variables) to the appropriate paths and the Option (string variable), if any, which can be found by opening a Command Prompt window and typing xcopy /?. (Note: You can type /? after any DOS command at a DOS prompt to list the available options for that command.) One more example would be to list all the files in a directory including subdirectories and subdirectories of subdirectories and all of their files.

  CommandLine = "dir """ & FileSpec & _

                             """ /s/b > """ & RedirectTo & """"

  Shell Environ$("comspec") & " /c " & CommandLine, vbHide

Here, the output of a Dir command is redirected to a file-path you specify in the RedirectTo (string variable). The /s/b are options to the Dir command that tell it to recurse throught its subdirectories and not to include header or summary information.

I used a variable for the file name so that I could more easily explain the benefit of encasing it in quotemarks. If you redirect to a file that has spaces in its name, or if there are spaces in the path specification itself, then the filename *must* be quoted to protect the spaces from DOS's desire to use them as delimiters. (That's what all those quotemarks in the Shell statement are for.) If the filename doesn't have spaces in it, the quotes aren't necessary BUT they don't hurt either. Hence, the above will work with either.

As for your PING question, something like the following should work:

     strIP = "4.17.23.1"

     Shell Environ$("comspec") & " /c ping " & _

              strIP & " > """ & RedirectFile & """", vbHide

Although you didn't specify it in your original post, I assume you want to use vbHide for the optional 2nd parameter to Shell. This hides the DOS window so that your user doesn't see it. If you want the DOS window to remain visible, you would use the vbNormalFocus BUT you must use a /k instead of a /c for the command processor argument. Basically, the /c tells the command processor "here comes a command and, when its finished executing, close the DOS shell it is running in" whereas the /k also tells the command processor that a command follows, but it instructs it to leave the DOS session running.

The above assumes you do NOT have to wait for this file to be completely written before your code continues executing. If you have to work with this file right after it is created, consider one of these (which makes your program wait until the DOS process is finished):

MICROSOFT'S OFFICIAL WAY

========================

See this link... http://support.microsoft.com/kb/129796

Note: This method doesn't use Shell -- it uses CreateProcessA.

FAST AND DIRTY METHOD

======================

Paste these lines into a Standard Module:

Private Declare Function OpenProcess _

        Lib "kernel32" _

        (ByVal dwDesiredAccess As Long, _

         ByVal bInheritHandle As Long, _

         ByVal dwProcessId As Long) As Long

Private Declare Function CloseHandle _

        Lib "kernel32" _

        (ByVal hObject As Long) As Long

Private Declare Function WaitForSingleObject _

        Lib "kernel32" _

        (ByVal hHandle As Long, _

         ByVal dwMilliseconds As Long) As Long

Call your Shell command with the appropriate Shell arguments placed in the parentheses:

PID = Shell( **Put Shell Arguments Here** )

And finally, paste the following IMMEDIATELY after the PID=Shell statement above (making sure to handle the possible error where indicated; i.e. stop the code from falling through to your other commands if the Shell failed):

If PID = 0 Then

     '

     'Handle Error, Shell Didn't Work

     '

Else

     hProcess = OpenProcess(&H100000, True, PID)

     WaitForSingleObject hProcess, -1

     CloseHandle hProcess

End If

Was this answer helpful?

0 comments No comments

5 additional answers

Sort by: Most helpful
  1. Anonymous
    2015-04-18T21:05:44+00:00

    Thank you. You have been very helpful. It will take some time to understand this information but , for now, you have me back up and running.

    Was this answer helpful?

    0 comments No comments