ABAP_to_the_Future

Designing a Report Interface 10.2
format that the technology the subclass isdedicated to uses, and these parameters
are adapted to the format that the inte rface event uses. Beca use the calling program
only knows about the interface, it’s blithely unaware that different technologies
use different formats to store rows and columns.
The code in Listing 10.20 and Listing 10.21 handle the events raised when a user
interacts with the SALV report. In both cases, they adapt the parameters of the
data the view works with into a uniform data format and then pass the event
onwards, where it will be picked up by the controller.
METHOD handle_link_click.
* No type conversions needed
RAISE EVENT user_command_received
EXPORTING ed_user_command = '&IC1'
ed_row
= row
ed_column = column.
ENDMETHOD. "Handle Link Click
Listing 10.20 HANDLE_LINK_CLICK Method
METHOD handle_user_command.
* Local Variables
DATA: ld_command TYPE sy-ucomm.
* Convert view specific data type to generic data type
ld_command = e_salv_function.
RAISE EVENT user_command_received
EXPORTING ed_user_command = e_salv_function.
ENDMETHOD. "Handle User Command
Listing 10.21 HANDLE_USER_COMMAND Method
With the HANDLE_LINK_CLICK method, you’re not doing any type conversions,
because you’re using the SALV definitions as the baseline. For the user command,
however, the generic data elem ent is set to be defined as SY-UCOMM, because (a)
that is the system field that always has the user command written to it automatically
in every single SAP program and (b) it just feels right. Who knows why the
authors of the SALV object felt the need to define th eir user command data element
differently—but they did, so this needs to be adapted to prevent a runtime
error, even though both definitions ar e 70 characters long. (Perhaps SAP disallows
treating data elements of the same length identically in routine parameters
in case one data element definition changes down the track.)
439