topic Re: AT Cursor Selection - Module call in Application Development and Automation Discussions

AT Cursor Selection - Module call

Former Member — Tue, 21 Jun 2016 13:13:34 GMT

Can someone help me explain the below example. The same can be found in the link.

http://help.sap.com/abapdocu_702/en/abendynpro_on_cond_abexa.htm

The function key settings for F2 has been assigned the function type 'S' and function code 'CS', which is necessary for a module with "At cursor selection" to be called.

What I do understand is when the field input1 is double clicked, the module c1 gets called since there is a field statement for the same - This is explained on the second last point.

What I don't understand is when the field input2 or input3 is double clicked, as per the explanation on the last point the module "cursor" gets called but not the module "c2". The reason as explained is when there are more than one module for cursor selection only the last one gets called. If this is the case the very last statement is also common for the field input1. So when input1 is double clicked why wouldn't it call the module "cursor" instead of the module "c2"?

Thanks,

Vikram.M

Re: AT Cursor Selection - Module call

Sandra_Rossi — Tue, 21 Jun 2016 16:36:28 GMT

I guess this example is used because it's not trivial to understand, and programmers often do this error.

MODULE AT CURSOR-SELECTION : http://help.sap.com/abapdocu_702/en/dynpmodule.htm#!ABAP_ADDITION_2@2@

It's just how it has been designed. As for MODULE AT EXIT-COMMAND (there can be only one).

Re: AT Cursor Selection - Module call

Former Member — Tue, 21 Jun 2016 18:00:50 GMT


Sandra Rossi wrote:

 It's just how it has been designed.

That is what I do not understand. If the design allows more than 1 module with "at cursor selection" to be present and only the last one will be called, then when the function code F2 is selected for the field input1, it should call the module "cursor" and not "c1", yes?

Re: AT Cursor Selection - Module call

Sandra_Rossi — Tue, 21 Jun 2016 21:11:40 GMT

I could test it in a live system. For input1, you're right, it calls c1. So the rule is more complex, and I came to the following conclusion.

There are three MODULE ... AT CURSOR-SELECTION possibilities:

Module for a given field:

FIELD m1field MODULE m1 AT CURSOR-SELECTION.

Chain of fields:

CHAIN.
  FIELD : m2field, m2field_bis.
  MODULE m2 AT CURSOR-SELECTION.
ENDCHAIN.

All fields:
```
MODULE m3 AT CURSOR-SELECTION.
```

When the PAI is called (any function code):

the PAI flow logic is processed sequentially, as usual
if a module AT CURSOR-SELECTION is found and function code is CS and function type is S then :
- If it's a m1-like module, and corresponds to the double-clicked field, (and in the previous lines there's no m1-like module corresponding to the double-clicked field - which was thus already processed/executed), it's executed.
- If it's one of type m2 or m3-like module, it's executed only if, in the following lines of the PAI, there's no other m2 or m3-like module, and there's no m1-like module corresponding to the double-clicked field.

Concerning your question about the dynpro generation, why it doesn't warn about the "incompatibilities", I don't know, but there are other similar situations, for instance CHAIN in the PBO being ignored at runtime but no warning/error at compile time.