To control the interplay between online user and the ABAP program, the graphics function modules offer a set of dialog parameters:

• STAT: status with which function module called

• M_TYP: type of message returned from graphics program

• RWNID: ID of window in which user input occurred

• PWDID: parent window for the window being opened

• WINID: ID of current window (existing or to be created)

• SUPER: marks current window as "exit window"

STAT is the central parameter. This parameter tells the function module which functions to perform on a given call:

• open a window and start the graphics program in it

• transfer data to the graphic window

• wait for input from the window

The most common pattern for programs allowing multiple windows is to place the various function module calls in a loop. A pass through the loop is made each time new input is received from the user. (See the programming scheme in "Waiting for User Input".)

The STAT value for calling a function module is changed depending on which of the three functions above are needed at a particular time. Usually, for example, a window must be opened on the first call, but not thereafter.

You need not use the dialog parameters in your application program. However, if you don't, the function modules assume particular default values for them. The default values for these parameters are the same, regardless of which function module you call.

You use the STAT parameter to tell a function module to wait for user input. A waiting function module does not return to the ABAP program until it has received input from a graphics program. This is true even if the input is only a report that a graphic window has been closed.

Every ABAP program that calls graphics function modules must ask one of the function modules to wait. This is because calling a Wait function module has the effect of "realizing" actions requested in No-wait function calls:

• Windows created in No-wait calls do not appear on the screen until the call to the waiting function module takes place.

• Data sent to existing windows in No-wait calls are not actually displayed until a Wait call to a function module happens.

A waiting function module receives input from all graphics programs, not just its own. All messages returned from any running graphics program are written to a common queue. A waiting function module intercepts all messages using this queue, regardless of their origin. (However, the function module returns to the ABAP program with a single message at a time.)

Thus it is only sensible for one function module at a time to be asked to wait for input. The waiter picks up all messages in the queue, and makes them available to the program at large.

All other function modules are called with a non-wait STAT value, and should be regarded as "output only" calls. They merely execute their other functions (opening new graphics windows and transferring data to them) and return to the ABAP program. Graphics programs called by non-waiting function modules are still running, however, after the module returns to the ABAP program.

The following example is a simple scheme for combining multiple calls to function modules in a program.

LOOP UNTIL (user input available)

In the above example, only the use of the STAT parameter is illustrated. (Other dialog parameters such as window parameters have been omitted.)

Here the programmer wanted to open several windows simultaneously, but not take input from the user until the last one is open.

The STAT values should change after the each time through the loop, depending on the input reported by FunctMod4.

In the above scheme, the windows created in the first (No-wait) calls do not appear on the screen until the last (Wait) function module has been called. As a result, no input to any window by the user can get lost.

The waiting function module handles received messages differently, depending on which graphics program sends them. If the messages are from its own graphics program, (for example, if GRAPH_3D receives a message from SAP Business Graphics), the function module sets the values of all export parameters and returns to the ABAP program.

However, when the waiter receives messages from graphics programs not its own (for example, GRAPH_3D receives a message from SAP Statistics), it has no information on the relevant export parameters and how to set them. In this case, the waiting function module has no choice but to return with invalid export parameters.

When the waiting function module returns, the ABAP program needs to know whether the parameters returned have valid values in them or not. (This can be determined by inspecting the M_TYP parameter.) If not, special processing is necessary to get the needed parameter values.

To learn which graphics program sent the message received, the ABAP program should check the RWNID parameter. RWNID tells the name of the window where the user input occurred. This window name ("window ID") also identifies the graphics program running in the window. (See the WINID and RWNID parameter descriptions for information on window ID formats.)

If (based on the value of M_TYP), the exported parameters already contain the returned information, the ABAP program can use them right away.

However, if the exported parameters are invalid, the ABAP program must call any function module associated with the graphics program, sending it a STAT value of 'R' (Reuse). This asks the function module to take parameter information out of static storage and set the appropriate return parameters.

For example, when the message comes from SAP Business Graphics, the ABAP program can call any of the Business Graphics function modules. It need not be the function module that opened the window in the first place.)