Relevance of OK_CODE

[Former Member]

Hey Guys,

Can anybody please explain the relevance of using OK_CODE instead of SY-UCOMM directly. I have been programming the USER_COMMAND_xxxx modules using the following code:

module USER_COMMAND_1000.

CASE SY-UCOMM.

WHEN '...'.

xxxxxxxx.

WHEN '...'.

xxxxxxxx.

ENDCASE.

end module.

What's wrong if I work this way and how does collecting the value of SY-UCOMM in OK_CODE help me?

Regards,

Madhur

[vani_krishnamoorthy · Accepted solution]

Hi Madhur,

SAP recommends that in dialog program always use OK_Code instead of sy-ucomm. Here is what the help says

<i>In your ABAP programs, you should work with the OK_CODE field instead of SY-UCOMM. There are two reasons for this: Firstly, the ABAP program has full control over fields declared within it, and secondly, you should never change the value of an ABAP system field. However, you should also always initialize the OK_CODE field in an ABAP program for the following reason:

In the same way that the OK_CODE field in the ABAP program and the system field SY-UCOMM receive the contents of the corresponding screen fields in the PAI event, their contents are also assigned to the OK_CODE screen field and system field SYST-UCOMM in the PBO event. Therefore, you must clear the OK_CODE field in the ABAP program to ensure that the function code of a screen is not already filled in the PBO event with an unwanted value. This is particularly important when the next PAI event can be triggered with an empty function code (for example, using ENTER). Empty function codes do not affect SY-UCOMM or the OK_CODE field, and consequently, the old field contents are transported.</i>

Hope this answers your question

Regards,

Vani

[Former Member · Accepted solution]

Hey All,

Thanks a lot guys for your help

Vani & Charles:

You both have been very helpful in answering my query You guys deserve the points and you got it!

Sandeep:

Thanks for your efforts... really, but I've got to be very discreet when awarding points. In fact, we all must be discreet about it and respect the system. This ensures that the efforts of a person are rewarded appropriately. I am not indicating that you did'nt make efforts (in fact, I've already acknowledged that ), but I guess Vani and Charles went a little further than that, hence the points. I hope you don't mind

Andreas:

<i>Dude!</i> A counter question is <b>NOT</b> an answer!! Still I appreciate your taking time out to answer my query. Thanks. I hope the answers by Charles and Vani will help you to understand <b>WHY NOT</b> use SY-UCOMM directly in Dynpros

Rest of the Gang:

Thanks a lot guys, I think this discussion has made all of us a little more knowledgable

Regards,

Madhur

[eyal_alsheikh]

Hi Madhur,

The quote above is from SAP library -> ABAP Programming

-> ABAP User dialogs -> Processing screens -> User actions on screens -> Reading Function codes.

Message was edited by: Eyal Alsheikh

[andreas_mann3]

Sorry Madhur ,

but i've never use sy-ucomm in a dynpro.

<b>Why</b> shall i do it ?

regards Andreas

[Former Member]

This is a long standing issue dating back many years. The general answer is that you control the OK_CODE field while SAP controls the SY-UCOMM field. You assign field OK_CODE to the OK code field in the screen painter and SAP copies SY-UCOMM to your OK_CODE field. Now you have control over the value. If you start invoking other code, like SAP utilities that display screens, you can be guaranteed that the value in OK_CODE will still be there, while you have no idea what SAP might be doing with SY-UCOMM.

This is a design decision that was probably made about 20 years ago when screen processing was introduced. In most cases, you can probably use SY-UCOMM and not have any problems but there are probably cases out there where SAP has done something tricky and you will have a problem.

Because there are unknowns out there, I always define an OK_CODE and do not use SY-UCOMM for standard screen processing. For me this is a long standing habit.

Is this the kind of information you were looking for?

[andreas_mann3]

Hi Madhur,

you've to differ btw. Dynpro (ok_code in element-list and query in module "user_command")

and report (query of sy-ucomm on event AT SELECTION-SCREEN or event AT user-command in an interactive list)

regards Andreas

[Former Member]

Hey Andreas,

My question is for Dynpro. As shown in the sample code in the original post, I am using SY-UCOMM in

module USER_COMMAND_xxxx.

Regards,

Madhur

[Former Member]

Hi Madhur,

I think you start using sy-ucomm instead of OK_CODE.

If you get any problem during the development process due to sy-ucomm, then that problem would provide some clue to you regarding the use of OK_CODE instead of sy-ucomm.

Else continue using sy-ucomm or OK_CODE..

Points!! :):)

Sandeep

[Former Member]

Hi Madhur,

OK_CODE acts just as a temporary variable that stores the value of sy-ucomm.

When user interacts with the screen elements, the function code that you have assigned is filled in the sy-ucomm field which is turn reflected in OK_CODE.

You can instead use sy-ucomm directly.

Hope that helps !!!

Sandeep

[Former Member]

Hey Sandeep,

Thanks for the reply. However, I am already aware that the value of SY-UCOMM gets transferred to OK_CODE and as I had mentioned through the sample code, I have already been using SY-UCOMM to process the function codes. This part is clear to me.

Still, there has to be some concrete reason for using OK_CODE instead of SY-UCOMM even if its done under special circumstances.

I am trying to understand the reason for using an additional variable even when processing can be done directly.

Regards,

Madhur