Entering content frame

Process documentationSynchronizing the Automation Queue Locate the document in its SAP Library structure

Purpose

The automation queue plays a central part in communication between the OO Control Framework and the Automation Server. It contains the buffered automation calls, and sends them from the backend to the frontend at special synchronization points. Once the automation queue has been processed at the frontend, the result is sent back to the backend.

The number of synchronization points is critical for the performance of your application. You can use the Automation Trace and the Performance Monitor to track this. Both tools are described in the Automation Queue Services section.

Process Flow

At certain points, the automation queue is automatically synchronized by the system:

Caution

The synchronization does not take place until after field transport to the screen. Consequently, the results of method calls that are processed by the automatic synchronization do not appear on the screen.

You can also synchronize the automation queue manually, using the method flush of class CL_GUI_CFW .

This graphic is explained in the accompanying text

If you program carefully, you can allow the last explicit synchronization to be carried out implicitly by the system.

Using Buffered Operations to Improve Performance

In general, you can improve the performance of your controls by applying the following processing sequence. Its aim is to split the calls to all existing controls into two groups for each PBO/PAI step:

As a result of this, you only need two synchronizations for all of your controls. However, you may need to repeat the "Get control attributes" part. For example, if you need a piece of information before you can decide what other information you require, you would need to get the information in two stages.

Reusing Values Within the Queue

If you call a method that returns results, you can use the returned values in a subsequent method call within the same queue without synchronizing the queue. The only prerequisite is that the parameters both use the same ABAP variable.

Buffered Method Calls to Get Control Attributes

When you use buffered method calls to get control attributes, you must note the following: The addresses of the ABAP variables into which the values are to be written are noted in the automation queue. The values are not passed to the variables until the synchronization. The addresses of the variables must remain valid up to this point. If a local variable no longer exists (for example, a local variable in a subroutine), the synchronization will cause a runtime error. The problem with this kind of error is that it does not show up in the Debugger, even when you select the setting Automation Controller: Always process requests synchronously.

The safest way to work with returned values is to use object attributes, because an instance of an object remains visible for as long as a reference variable is still pointing to it.

This graphic is explained in the accompanying text

The safe solution is to query the control attributes in a subroutine that synchronizes the automation queue at the end and at every exit.

When you process events, it is a good idea to get the attributes of the control that triggered the event and then to synchronize the automation queue.

Example

(Pseudosyntax): Suppose you want to read the selected node of a tree control and the selected text of a textedit control.

FORM GET_CONTROL_PROPERTIES.
DATA: tree_selected_node, combobox_selected_node.
CALL METHOD tree->GET_SELECTED_NODE
IMPORTING
NODE_KEY   = tree_selected_node
      <Error handling>
CALL METHOD textedit-> GET_SELECTION_POS
IMPORTING
FROM_LINE = from_line
            FROM_POS  = from_pos
            TO_LINE   = to_line
            TO_POS    = to_pos.
<Error handling>
CALL METHOD CL_GUI_CFW=>FLUSH
<Error handling>
ENDFORM.

 

 

 

 Leaving content frame