Synchronizing the Automation Queue 
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
At certain points, the automation queue is automatically synchronized by the system:
At the end of every PBO event:
CautionThe 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.
End of the caution.After a handler event for a system event has been processed.
You can also synchronize the automation queue manually, using the method flush of class CL_GUI_CFW.
Note
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:
Get control attributes
Buffered method calls to get all control attributes that you require
Synchronize the automation queue
Processing / calculations
Set control attributes
Buffered method calls to set the control attributes
Synchronize the automation queue
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.
Note
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.
Note
(Pseudosyntax): Suppose you want to read the selected node of a tree control and the selected text of a textedit control.
Syntax
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.