Where are We?

There are times when it would be handy to be able to tell exactly where we are while a JOB (or any other process family) is running. For example, if an overflow error occurs, it would be useful to be able to identify the process name, type, frame, etc, in order to report the error. APPX provides the PDF's --- PROCESS NAME and --- PROCESS TYPE, but there aren't any PDF's that identify the frame, image, or frame class. However, there is a way to do it using some special RT calls. Consider the following subroutine called WHERE ARE WE:

SET  1EX WORK PROC NAME = --- PROCESS NAME
SET  1EX WORK PROC TYPE = --- PROCESS TYPE
SUBR 1EX WHERE ARE WE (FRAME/IMAGE) SUBPROCESS END? N FAIL 0

First we save the process name and type into some work fields, and then call another subroutine via a SUBR command. These three lines *must* be invoked via a GOSUB or COPY command. Both the GOSUB and COPY commands actually copy the code into the calling routine, so the PDF's PROCESS NAME and PROCESS TYPE will refer to the parent process, not the subroutine called WHERE ARE WE. The RT calls that identify the frame, image, etc, always identify the last parent process, therefore in order to get the information on the process we really care about, we have to put those calls in another subroutine and invoke that routine as a separate process, thus making the current process the latest parent (Confused yet?). Here is the WHERE ARE WE (FRAME/IMAGE) routine:

    SET     1EX WORK IMAGE NO =
    SET     1EX WORK FRAME NO =
    * save work fields so not to disturb calling program
    STORE   --- TEMP 1 FIELD
    STORE   --- LI FIELD
    * get frame no
    SET     --- LI =
    PASS    --- LI FIELD SHARE? Y
    CALL    ,RT_GET_FRM_SNO RESIDENT? Y END? N FAIL 0
    SET     1EX WORK FRAME NO = --- LI
    * get image no
    SET     --- TEMP 1 =
    PASS    --- TEMP 1 FIELD SHARE? Y
    CALL    ,RT_GET_ALT_IMG_NO RESIDENT? Y END? N FAIL 0
    CNV BIN 1EX WORK IMAGE NO = --- TEMP 1
    * get frame class
    SET     --- TEMP 1 =
    PASS    --- TEMP 1 FIELD SHARE? Y
    CALL    ,RT_GET_FRM_CLASS RESIDENT? Y END? N FAIL 0
    CNV BIN --- LI = --- TEMP 1
    * Value of LI corresponds to Token values for Frame Class
    IF      --- LI EQ 0
T   SET     1EX WORK FRAME CLASS = RECORD
    IF      --- LI EQ 1
T   SET     1EX WORK FRAME CLASS = RANGE-START
    IF      --- LI EQ 2
T   SET     1EX WORK FRAME CLASS = RANGE-END
    IF      --- LI EQ 3
T   SET     1EX WORK FRAME CLASS = PAGE-START
    IF      --- LI EQ 4
T   SET     1EX WORK FRAME CLASS = PAGE-END
    IF      --- LI EQ 5
T   SET     1EX WORK FRAME CLASS = REPORT-START
    IF      --- LI EQ 6
T   SET     1EX WORK FRAME CLASS = REPORT-END

The code is self explanatory. Since this is invoked as a SUBR, a RETURN statement is not required (nor can it be used).

When required, you can perform a GOSUB XXX WHERE ARE WE, and the work fields PROCESS NAME, PROCESS TYPE, FRAME NO, IMAGE NO and FRAME CLASS will identify your location.


Windows Desktop Integration

The 4.1 Java Client provides some extremely useful Windows desktop integration features, such as sending and receiving files to or from a user's PC and opening a document on the user's PC. Consider the following code:

SET 	-- TEMP 79 =     http://www.appx.com
PASS 	-- TEMP 79 FIELD SHARE N
SUBR  	-- LOAD FILE ON CLIENT DETACHED N END? N

This will cause Windows to invoke the default web browser and open the specified web page. You can also pass the name of a file, and so long as Windows knows what program is associated with that file extension, it will automatically load that program and pass the file name as an argument to it. For example, we could pass a file name such as 'budget.xls' and Windows will open the budget.xls document in Excel. This behaves exactly the same as the 'start' command in DOS. For example, you could open a DOS box and type 'start budget.xls', and Windows would do the same thing: start Excel and load the budget.xls document.

If the file you want to open is not associated with the right program (or any program at all), you can also pass the name of the program to be used, prefixing it with an '@'. For example, passing '@keavt.exe cansys' will cause Windows to load the KeaTerm terminal emulation program and open the 'cansys' profile. In some cases, Windows may not be able to find the 'exe' file, so you may have to provide the full path name.

But what if you need more control over the program you want to start, such as specifying a starting directory, or other attributes? Windows Shortcuts might provide the answer. Simply create a shortcut with the parameters you need, and then pass the name of the shortcut file itself, i.e., '@c:\windows\startm~1\window~1.lnk'. This will run the 'Windows Update' commonly found on most 'Start' menus. Note that you cannot use long file names with embedded spaces in this case. You must use the 8.3 DOS file names to correctly run the shortcut.





For additional information, contact tips@cwi-appx.com

[back to top]