2021 Sep 23 10:55 AM
2021 Sep 23 10:56 AM
2021 Sep 23 12:19 PM
Step 1. Read the documentation on select-options and how their data is structured
Step 2. Define appropriate types either in an interface, or in the data dictionary (if FM is to be RFC)
Step 3. Create a function module (and function group if not using an existing one) frdric.girod
Step 4. Create parameters with the type of the select-options you need as defined in Step 2.
Step 2, courtesy of sandra.rossi , many thanks.
2021 Sep 24 6:36 AM
I like this way, we put ideas, and you do the job of answering 🙂
thanks matthew.billingham
2021 Sep 24 8:55 AM
2021 Sep 23 12:59 PM
matthew.billingham It's worth an answer, and I think you miss the creation of the type between Step 2 and 3, I would recommend defining the type in an interface (or DDIC if it's a RFC function module).
2021 Sep 23 2:49 PM
and we don't know if there is a function group ..
(but Why they still using FM ?!?)
2021 Sep 24 7:40 AM
Have a look at the "good example" under
The example uses PARAMETERS, but of course, the same holds for SELECT-OPTIONS.
BR
Horst
2021 Sep 24 8:56 AM
2021 Sep 24 9:06 AM
Because it is generally sufficient for dealing wit classical dynpros in local classes of function pools. You can do it with singletons if you like but I don't see a benefit of multiple objects dealing with one program-global dynpro.
I know, we have https://help.sap.com/doc/abapdocu_latest_index_htm/latest/en-US/index.htm?file=abenstatic_class_sing..., but simply encapsulating classical dynpros runs under exceptions for me.