As described in the ABAP Development: HowTo handle frontend events document, there are multiple options to receive and handle event from the GeoMap component. In this example we focus only on the implementation in an FPM environment. Despite the differences in how the event handler get invoked and the event data is passed, the actual event handling is equal in all cases.
In case the event is handled directly in method HANDLE_EVENT or in the Service Provider HANDLE_MAP_EVENT you need to push the context menu to the frontend by calling method CONTROL_ADAPTER->PUSH_CONTEXT_MENU( LV_CTMENU ). In the special event handler GET_CONTEXT_MENU this is not the case!
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 open a popup instead of a context menu.
Handling the context menu request
Pressing the right mouse button leads to backend event IF_VBI_CONST=>GC_CONTROL_EVENT-CT_MENU_REQ. This event is per default passed on to method GET_CONTEXT_MENU. 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
- IS_POINTER_POS: position of the mouse pointer in 3D-/geo-coordinates when the event was raised.
The GET_CONTEXT_MENU method is expected to return an instance of CL_CTMENU. Class CL_CTMENU is probably already well known from the classical SAPGUI programming. It allows to interactively define a context menu with multiple levels. You simply define the actual context menu within this instance and the Visual Business component will display it according to your definitions.
The context menu is always defined fully dynamic by the application. However, the class supports also the use of templates via method ADD_MENU. With this method you can copy the definitions from an existing instance to the one passed in the event, which allows you to hold context menu templates in your application code and to simply copy them to the actual menu.
Further it is also possible to define context menus statically in a GUI status. Class CL_CTMENU supports also loading the context menu from a given GUI status with method LOAD_GUI_STATUS.
Context menu for an object
You receive type and GUID of the object the event was raised on. Base on this information you can dynamically create a context menu specifically for this object instance.
For each entry in the context menu you need to provide an application defined FCODE, which can later be handled in method HANDLE_FCODE.
The following code sample from the sample program VBI_GUI_TEST shows the event handling and the dynamic definition of a context menu:
Context menu for the map
In general the context menu will be requested for a certain object, given via its GUID. However, the user can also request a context menu on the map itself. In this case we cannot pass a GUID in the event data, but we provide a geo-position as IS_POINTER_POS. The given position is determine from the back-projection of the mouse pointer position onto the map. With this information it is possible for application to provide the interactive creation of objects on the the map. The user will not need to enter geo-coordinates or address data. He just click on the position at the map.
Since the actual creation function needs to be selected by the user from the context menu, the creation can only be executed on the second round trip in the FCode handling. For this event we cannot provide the geo-position, sinse the mouse pointer has already been move. Thus it is absolutely necessary to remember the position on application side from the context menu creation event until the FCode handling.
Handling selected functions
After the context menu is presented to the user he can select one of the provided functions. This selection leads to backend event which ID is the FCODE of the selected function.
Per default this event is passed on to handler method HANDLE_FCODE and the actual FCODE is given as import parameter IV_FCODE. The following code sample from program VBI_GUI_TEST shows the a possible handling of standard functions: