on 02-09-2005 11:49 AM
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sorry Madhur ,
but i've never use sy-ucomm in a dynpro.
<b>Why</b> shall i do it ?
regards Andreas
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
User | Count |
---|---|
103 | |
12 | |
11 | |
6 | |
5 | |
4 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.