回想一下,为什么要在AT SELECTION-SCREEN事件验证用户输入条件?好像是第一次做ABAP培训中老师提到的,当时也没有觉得有什么问题,以后在程序中也就按照这样的思路去写代码了.像下面简单的代码,对我来说已经是司空见惯了.
SELECT-OPTIONS: s_matnr FOR mara-matnr. AT SELECTION-SCREEN. |
从逻辑上来看没什么问题,这样可以确实要求用户必须输入物料号这个条件.
但是当用户输入多个物料号的时候,麻烦来了.用户一般已经在其它地方将需要输入的物料号复制到剪贴板上,希望能一次粘贴到选择条件中.但是有了上面的语句,用户必须复制一个物料号,粘贴到s_matnr对应的编辑框内,然后切换回物料号列表的窗口,复制剩余的物料号,点击"多项选择"按钮再进行粘贴,无形中多出了三个操作步骤.
如果每天使用这样的报表使用几次,那可能也算不了什么.但是如果要几十甚至上百次使用这样的报表,您不觉得烦吗?
如果在AT SELECTION-SCREEN事件中写了比较复杂的验证代码,那就更麻烦了.因为用户每次点击"多项选择"按钮都会触发AT SELECTION-SCREEN中的所有代码,那么对于用户来说,每次操作都需要一定时间的等待!另外一方面,AT SELECTION-SCREEN中的所有代码在触发START-OF-SELECTION事件前还会执行一次,对系统来说也是不必要的资源浪费.
还是看看关于AT SELECTION-SCREEN的Online help吧!
You should only perform very expensive checks with AT SELECTION-SCREEN
考虑到上面的情况,大多数情况下面,我们还是把验证用户输入条件的代码放在START-OF-SELECTION事件处理中比较合适.
---------------------------------------------------
对AT SELECTION-SCREEN又做了一些研究,如果在事件处理中加一些限制条件后,基本上和写在START-OF-SELECTION事件中效果相同,不过出错时的提示界面更友好,用户可以直接修改输入值,这也是使用START-OF-SELECTION事件不好的地方.代码框架如下:
IF sscrfields-ucomm = 'ONLI' OR sscrfields-ucomm = 'PRIN' OR sscrfields-ucomm = 'SJOB'. * Your code here ENDIF. |