As described in the ABAP Development: HowTo handle frontend events document, there are multiple options to receive and handle events from the Visual Business component. In this example we focus only on the default implementation in a derived application class. Despite the differences in how the event handler gets invoked and the event data is passed, the actual event handling is equal in all cases.
In case the event is handled inside the application via method HANDLE_EVENT or in Service Provider HANDLE_MAP_EVENT you need to push the context menu to the frontend by calling method CONTROL_ADAPTER->PUSH_DETAILS( LV_DETAILS ) from the Service Provider. In all other cases this is done automatically.
The requirement for this extra call in the internal handling gives you the freedom for alternate reactions of the application to the given frontend event. If you find this a better UI approach you may update the context of a view next to the map or open a popup instead of showing the detail window on the map.
Handling the detail window request
Pressing the right mouse button leads to backend event IF_VBI_CONST=>GC_CONTROL_EVENT-DETAIL_REQ. This event is per default passed on to method GET_DETAILS. The associated data is passed as import parameters to this specific handler method.
You receive the following information:
- IV_OBJECT_TYPE: type of the object the event is raised for. Object types are defined as constants in interface IF_VBI_CONST attribute structure GC_SCENE_OBJECT_TYPE.
- IV_OBJECT_GUID: GUID of the object the event is raised for
There is a default implementation of the GET_DETAILS method which will create a simple details window from the data in the DESCRIPTION table of an object. In this table you can provide not just tooltip text but also details information. The scope of a text in defined by its CATEGORY. In order to use a description entry for the details window its category have to be IF_VBI_CONST=>GC_DESCR_CATEGORY-DETAIL or IF_VBI_CONST=>GC_DESCR_CATEGORY-BOTH (details + tooltip). Further you have limited control about the appearance of the entry by specifying the PART. With IF_VBI_CONST=>GC_DESCR_PART-CAPTION you make it a caption, with IF_VBI_CONST=>GC_DESCR_PART-SUBCAPTION a subcaption, and with IF_VBI_CONST=>GC_DESCR_PART-BODY a normal text line. The layout is always single column. If you need more control about the content and the layout you can overwrite the base implementation.
The GET_DETAILS method is expected to return an instance of CL_VBI_OBJECT_DETAILS_DESCR. This class allows to interactively define a detail window with limited layout variations. You simply define the actual window content within this instance and the Visual Business component will display it according to your definitions.
The object supports:
- One or two column layout,
- a Caption and a sub-caption,
- a horizontal toolbar, and
- a picture.
The detail window content is defined fully dynamic by the application. However, the class supports also templateing via method SET_FROM_TEMPLATE. With this method you can copy the definitions from an existing instance to the one return on the event, which allows you to hold detail window templates in your application code and to simply copy them to the actual window.
If you add links to a text column or add links/buttons to the toolbar you need to provide an application defined FCODE for each, which will be returned as event ID, if the user presses the link or button.
The following code sample from the sample program VBI_GUI_TEST shows the dynamic definition of a detail window:
The sample code uses the TYPE given in the event data. For spots we use a one column layout and for links a two column layout.
For more details on the dynamic detail window creation you can also check out those specific HowTo:
- HowTo use icons
- HowTo get two text columns
- HowTo add buttons or links to the toolbar
- HowTo add an image
- HowTo change the default layout
Handling selected functions
If the detail window shows links or button the user can click them. This leads to backend event with the FCODE of the selected link or button as as event ID. Per default those events are handle in application class method HANDLE_FCODE.
The following code sample shows the reaction on an FCODE by just presenting a message:
Opening a Detail window without request
Sometimes you may wish to open a details window even without a user request. As an example imagine you show an address location with a spot object. Then it would be great to directly open a detail window which shows the full address.
The actual method for pushing a details window to the frontend is PUSH_DETAILS of the control adapter. You can access it via APPLICATION->SERVICE_PROVIDE->CONTROL_ADAPTER->PUSH_DETAILS() or any part of this depending on you code location. In the default case you just provide the detail window descriptor as IV_DETAILS. In that case the object the detail should belong to is taken from the last received event context. In case there is no event or you want to change the context (object) you need to provide also the GUID of the context object to the method via IV_OBJECT_GUID.
In case you you have no access to the application, because your code resides in a WDA or FPM context, you can call method PUSH_DETAILS on the component controller of WDA component VBI_WD_VISUAL_BUSINESS.