Abnormal behaviour of AT SELECTION-SCREEN ON <field> event

[Former Member]

Hi friends,

I'm facing an issue where a select option is getting first record overwritten with the record in its header line.

Check this code:

AT SELECTION-SCREEN ON BLOCK customer.

     LOOP AT t_cosel.

          MOVE-CORRESPONDING t_cosel TO s_kunnr.

          APPEND s_kunnr.

     ENDLOOP.

Like this I am populating the select option s_kunnr and its succesfully getting 3 records populated.

The next event is:

AT SELECTION-SCREEN ON s_exkun.

As soon as above line executes, the first row in s_kunnr[] is overwritten with the last record that was appended in s_kunnr[] which is still saved in the header s_kunnr.

Why is this happening?

The field s_kunnr is not in the block customer and fields s_exkun and s_kunnr are in the same block on selection screen,

Anyone faced an issue like this before? Kindly help.

Thanks,

Ali

Message was edited by: Matthew Billingham - incorrect characters replaced. Fortunately, I can read Greek.

[SwadhinGhatuary]

Hi,

Translate to English for understanding

[former_member201275]

If you provide this in English it would be easier to get more help here to be quite honest.

Also can you please post the code of your complete Selection Screen statement, from beginning until end of the AT Selection screen events.

[Former Member]

Guys. Aplogies for the inappropriate text, i have no idea why browser did this to the text i wrote.

Here i paste the sample code again:

Check this code:

AT SELECTION-SCREEN ON BLOCK customer.

     LOOP AT t_cosel.

          MOVE-CORRESPONDING t_cosel TO s_kunnr.

          APPEND s_kunnr.

     ENDLOOP.

The next event is:

AT SELECTION-SCREEN ON s_exkun.

[gowtham_raj]

Hi Ali,

AT SELECTION-SCREEN ON BLOCK customer.

     LOOP AT t_cosel.

          MOVE-CORRESPONDING t_cosel TO s_kunnr.

          APPEND s_kunnr.

*************************************************************************************

          CLEAR s_kunnr. 

*************************************************************************************

     ENDLOOP.

Add clear statement as mentioned above and check

Regards,

G

[Former Member]

Hi Gautham,

I know that is one solution.

I was only keen to know why would record in s_kunnr header line overwrite record at index 1 in s_kunnr[] table, when the on screen event is on some other select option s_exkun?

Or to rephrase, why screen event on field s_exkun make changes to field s_kunnr?

Thanks,

Ali

[former_member201275]

It is because when you are filling t_cosel it is running the AT SELECTION-SCREEN events, it is not the second AT SELECTION-SCREEN causing the problem.

Put a break-point just after both your at selection screen statements and then you can quite easily see what is happening.

[gowtham_raj]

Could you please paste your code snippet here, which will help in fixing it.

Pls note : I have tried the same with sample code. It is not happening for me.

Regards,

G

[Juwin]

You shouldn't be changing/filling values in the select-options in AT SELECTION-SCREEN event.

For filling in initial values into the select-options, you should use INITIALIZATION. After user input, try not to change the values that the users have entered. If at all you need to change the values, you should do that in START-OF-SELECTION.

Thanks,

Juwin

[SuhaSaha]

Why not AT SELECTION-SCREEN OUTPUT??

[Juwin]

Because, it is called everytime the screen is output.... the screen is output after each user input (except F8), which means that the select-option will be filled in many times... user input can be as simple as an "Enter" press.

Thanks,

Juwin

[SuhaSaha]

I know ... Maybe i should have explained my question, my bad.

But if you are filling up your screen parameter based on some other variable, do you still suggest using the INITIALIZATION event?

[Juwin]

If one parameter is dependant on another user-entered parameter, then INITIALIZATION is not the correct event.

I have seen parameters dependant on each other, but not select-options. Can you please explain the scenario where you would be using this?

Thanks,

Juwin

[Juwin]

By the way, the simplest solution to the original problem is to use a workarea for appending new entries into the select-options.

data: ls_kunnr like line of s_kunnr.

MOVE-CORRESPONDING t_cosel TO ls_kunnr.

APPEND ls_kunnr to s_kunnr.

Thanks,

Juwin

[SuhaSaha]

I have seen parameters dependant on each other, but not select-options. Can you please explain the scenario where you would be using this?

May be doc types (select-options) dependant on company code.

[matt]

Almost - but if s_kunnr table is empty and t_cosel isn't, you need to load the first entry of t_cosel into s_kunnr header.

[Former Member]

Hi Juvin,

The screen is a little complex, if user has entered a worklist object, I need to override the s_kunnr selection given by user. This has to happen on selection screen event only as user may change the worklist object again.

This was the only solution I had.

[matt]

I fixed the display of the code for you in your original post.

In addition to what others have written (that you shouldn't be doing this in the validation events), I would add that this is a good example of why you should not use of tables with header lines, and if you can't (e.g. with select options), don't use their header lines.

The reason you get your symptoms is that in the selection screen, it is the header line of table s_kunnr which is displayed. So that will naturally be the last value it held.

You should rewrite your code as follows.

AT SELECTION-SCREEN ON BLOCK customer.

   LOOP AT t_cosel INTO cosel_wa.

     MOVE-CORRESPONDING cosel_wa TO s_kunnr_wa.

     APPEND s_kunnr from s_kunn_wa.

   ENDLOOP.

   " This next bit is necessary to ensure the display is as expected

   IF s_kunnr[] IS NOT INITIAL.

     READ TABLE s_kunnr[] INDEX 1 INTO s_kunnr.

   ENDIF.

Where cosel_wa is LIKE LINE OF t_cosel and s_kunnr_wa is LIKE LINE OF s_kunnr

(Also, put the code into at least a form of its own, so that you can define some of the variables as locals - global variables are bad as you have seen (s_kunnr is global - both as table and header line.).

[Former Member]

Hi Guys,

Thanks for all those inputs but my query was very simple, and I would rephrase it

"Why on screen event on one field modifies another field".

OR

"Why header line of field s_kunnr is appended at index 1 to table s_kunnr[] when on screen event for field s_exkun is triggered".

I still assume its unanswered.

And about the problem, i found a simple solution that is inserting at index 1 than appending:

AT SELECTION-SCREEN ON BLOCK customer.

     LOOP AT t_cosel.

          MOVE-CORRESPONDING t_cosel TO s_kunnr.

          "APPEND s_kunnr.

          INSERT s_kunnr INDEX 1.

     ENDLOOP.

I still seek an answer for the question.

Thanks,

Ali

[matt]

The behaviour has been fully explained by several people. I suggest you re-read the answers supplied so far.

Thread locked.