In this section you find information about what processing you can add for method GET_DATA
, which is the heart (processing part) of your feeder class. It manages events from the Floorplan
Manager (FPM), any you might raise in your code, and most importantly for you, the events triggered by the user (line selection, pressing a button, etc.):
Depending on the event, this method goes to work, getting personnel numbers, running the report in the back end and putting the final output into the Document Container, then modifying headers and raising its own events (setting the previous and next buttons to in/active) if necessary.
Note
If you want to re-implement an Java application, you should be able to reuse the code that calls the back end report and returns a document output here, either by cut and paste, or better still, by encapsulating it for both applications. This code is different for every report, so no example is added here. However, the following steps should give you an idea.
Before you start, have a look at the attributes starting GC_EVENT*
of your super class. These are the standard reporting events that you can react to in your feeder class.
Then see in key block Process
to find out what processing you can add for which events. Depending on your scenario, and thus depending on the buttons you have on your screen, you’ll need varying event processing.
If you have Previous and Next buttons, see Event GC_EVENT_NEXT and GC_EVENT_PREVIOUS for LIST GUIBBs
If you have a form with a ‘Show’ button or an application specific button, for example a Calculate
button in a salary calculator report, see Event GC_EVENT_NEXT_VALUE
and GC_EVENT_PREVIOUS_VALUE for FORM GUIBBs
As with all your redefinitions, call the super method GET_DATA
at the start of your code.
In all cases add processing to the FPM event LEAVE_INITIAL_SCREEN
.
See the following sections to find out what processing you can add to method GET_DATA
: