Tags:
create new tag
view all tags

Invoking Windows Shell Functions

In order to invoke a Windows shell function (such as a batch file or executable) from APPX for Windows, you can use a syntax similar to the following. (You'll have to break the SET statement apart into multiple APPENDs, but it is presented here as single strings, for clarity.)

Current APPX/Windows Versions

The method has changed over the years, based on changes in APPX and Windows. Generally speaking, code like the following should allow you to run any Windows command:

      SET      --- TEMP 2K                    =      /w cmd.exe /c "
      APPEND   --- TEMP 2K                    0  --- TEMP 512
      APPEND   --- TEMP 2K                    0      "
      RUN      --- TEMP 2K                                 END? N  FAIL 0

This assumes the command we want to run is already formatted in --- TEMP 512. We enclose the entire command in quotes in case of embedded spaces. The '/w' switch tells APPX to wait for the command to complete before continuing. If you don't need to wait, you can leave that switch out.

You can also use the full path & file name of a file directly in the RUN command, ie, RUN C:\WINDOWS\SYSTEM32\NOTEPAD.EXE, however note that APPX will not wait for the command to complete. If you need to wait for the command to complete, use the '/w cmd.exe /c' syntax. Remember that when you use the RUN command, it will be executed on the server, not the client. If you need to run the command on the client PC, see .CLIENT LOAD URL.

To pass parameters to the command, simply execute PASS <field name> or PASS <Filename>, then append a $* to your command. For example:

      SET      --- TEMP 80                    =      APARAMETER
      PASS     --- TEMP 80                    FIELD            SHARE? N
      PASS     CAR CUSTOMER                   FILE             SHARE? N
      SET      --- TEMP 79                    =      D:\TEST.BAT $* 
      RUN      --- TEMP 79                                 END? N  FAIL 0

Executing a PASS with the File parameter will pass the complete path of that file to the command (without the .dat extension).

You can also control the order the parameters are PASSed. The '$*' syntax will PASS the parameters in the order of the PASS statements, but you can also refer to '$1', '$2', etc. In the example above, if we executed 'D:\TEST.BAT $2 $1', the batch file would receive the path to CAR CUSTOMER first, followed by the contents of --- TEMP 80.

See Passing Fields or File Names for more information passing values to external commands.

Troublehshooting

If you can't get your command to execute the way you expect, try logging on to the server console and running the client directly on the server. Use the 'Local' tab to connect to the engine. You will be able to see any messages, dialog boxes or errors that appear.

Older APPX/Windows Versions

The following might be useful if you are running very old software.

Windows NT, APPX 4.0.2 and after:

SET --- TEMP 132 = cmd.exe /c C:\APPX\scripts\test.bat 
RUN --- TEMP 132

Windows 9x, APPX 4.0.2 and after:

SET --- TEMP 132 = C:\command.com /c C:\APPX\scripts\test.bat 
RUN --- TEMP 132

Windows NT, prior to APPX 4.0.2:

SET --- TEMP 132 = cmd.exe /c C:\\APPX\\scripts\\test.bat 
RUN --- TEMP 132

Windows 9x, prior to APPX 4.0.2:

SET --- TEMP 132 = C:\\command.com /c C:\\APPX\\scripts\\test.bat 
RUN --- TEMP 132

In the above example, "test.bat" contains some DOS copy commands. DOS commands (such as 'copy') don't work directly from APPX, because we are using a Windows "exec" function, which only knows how to start Windows programs. But running command.com from Windows, with the "/c" switch, creates a temporary DOS shell, which can then execute a DOS batch file.

The "/c" after cmd.exe and command.com specifies that the command interpreter is to perform the command specified by the string following it, in this case a batch file, and then stop.

Note that you can use option 6)Upper/Lower in the ILF editor to get lower case characters, such as 'cmd.exe'.

In releases 4.0.1 and prior, the double backslashes ("\\") are necessary to pass a single backslash ("\") thru to the windows shell, since backslash is used in DOS to denote special treatment of the following character.

In release 4.0.2 and after, the double backslash is no longer required.

Running command.com /c or cmd.exe /c is only necessary when invoking non-Windows native applications. This includes commands one would normally execute from the DOS popup box.

If you want to run a Windows-native application (such as notepad, or MS Access), you can invoke this directly without the command.com or cmd.exe /c prefix.

Without a preceding backslash, a "$" is an indicator of a substitution in the RUN command string based on a PASS statement. A backslash preceding a "$" tells APPX not to do a substitution but to allow the "$" to remain in the RUN command string.

(And the '%' symbol?)


In some applications, you might not want the DOS box to disappear after the external execution. For example a batch file that performed:

echo  -  display statement in the DOS box.

copy  -  execute statement and display in DOS box.

pause -  display "Press any key to continue" and 
         wait for user to press enter before 
         proceeding.

choice - display the message, waited for user to 
         make a valid selection 

To accomplish this, make a copy of COMMAND.COM and put it into a test directory. In the PROGRAM tab of PROPERTIES for this new file, deselect the "Close on Exit" check box. Then modify the APPX subroutine to invoke this test copy of COMMAND.COM. Now everything should continue to work fine and the box remain on screen. The title bar should at the end say: "Finished - " when complete.


The 4.0.2 change making double backslashes no longer required (ECR #3315) had a negative effect to the PowerQ application (ECR #4799).

After upgrading 3.4 to 4.0.2, a print job submitted to PowerQ and then released would continually print to the printer instead of stopping after the requested number of copies.

The reason was that the print queue daemon process was not getting back the results from the lpcommand as submitted by command "008 SUBMIT PRINT JOB". This command, as stored in the COMMANDS file, contained double backslashes. When these were changed to single backslashes the problem went away.


Under ECR #4799, the before and after for the command "008 SUBMIT PRINT JOB" are:

Before:

====================== = =================================== 013 REMOVE DIRECTO+------------------------------------------------+ 014 SUBMIT JOB & Command String & 015 GET SESSION PI& & 016 KILL TASK &cat6 & 017 VIEW FILE &{PRINTQ.HEX OPTIONS}6 & XX8 SUBMIT PRINT J&{BANNER FILE}6 & &{PRINTQ.PATH FILE}6 & &|lp -oraw6 & &{PRINTQ.SUBMIT DETAIL}6 & &2>&1 |awk '/^request id is/{print "0" \$4}6 & &/^\\/usr\\/bin\\/lp/{print "1" \$0}' & & & & & +------------------------------------------------+

After:

000 GET HOST NAME +------------------------------------------------+ 001 CANCEL PRINT J& Command String & 002 GET PROCESS ID& & 003 COPY A FILE &cat6 & 004 REMOVE FILE &{PRINTQ.HEX OPTIONS}6 & 005 GET GROUP LIST&{BANNER FILE}6 & 005 START BACKGROU&{PRINTQ.PATH FILE}6 & 006 LOOK FOR PRINT&|lp -oraw6 & 007 GET SYSTEM PRI&{PRINTQ.SUBMIT DETAIL}6 & 008 SUBMIT PRINT J&2>&1 |awk '/^request id is/{print "0" \$4}6 & 009 GET DIRECTORY &/^\/usr\/bin\/lp/{print "1" \$0}' & 010 GET NAME FROM & & 011 GET SYSTEM JOB& & 012 RENAME A FILE +------------------------------------------------+

Comments:

Read what other users have said about this page or add your own comments.



Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r4 - 2020-05-12 - JeanNeron
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback