OUFFF OK!!!!, just to clarify what is the only good answer to the question:
The problem risen here is that following a user action, the context may have changed and you need to reflect that change in the ALV.
Simple example:
I had that vendor blocking program to do. I was displaying an alv of the selected vendors with one of the fields being the block status. Then at the push of a button, I was blocking the unblocked vendors one by one, modifying the blocking status field of the feeding internal table along the way.
If I had not done anything specifically to refresh the ALV, after button action was completed, the block fields on the screen would have not been updated accordingly.
So, as one guy said above, the trick is crazy simple:
selfield-refresh = 'X'!!!!
As you know, to respond to user action you have to pass a user command form to your ALV call. The structure of that form is mandatory and as below(you can change the namings as you like, as long as you have a ucomm field followed by a slis_selfield).
And bingo, if you change back the parameter selfield-refresh to 'X', it will trigger automatically a refresh from your modified internal table that feeds your ALV
form user_command using ucomm type sy-ucomm selfield type slis_selfield.
...
...
selfield-refresh = 'X'.
...
...
endform.
Bluesky
