Last year I had to solve one interesting problem of unusual screen sequence processing.
That was a dialog program. I had to implement a screen behaviour that is similar to operation PRT screen of CO02. I have, let’s say, a screen A with a table control. To add new entries, I click a button and get a popup screen B. After entering some values I can either click one button to add an entry and get back to screen A (with a new line in the table control), or click another button so that a new line will be added to the table control (and shown there), but popup screen B remains so that I can input values for one more line.
The problem, is: If in PAI of the popup screen I just add a new line in appropriate internal table, screen A is not updated because I stay in screen B (and PBO of screen A is not run). I could probably use DYNP_VALUES_UPDATE from screen B to force the update of screen A, but with table control I will have to handle scrolling – this is too complicated. I tried to look at CO02 code to understand how SAP does that but it’s one of those programs where they use screen sequence control functions, making it extremely difficult to analyse.
I have solved my problem by setting a global variable in PAI of screen B to some value corresponding to popup call, then checking the variable in PBO of screen A (after the LOOP is over and table control is updated to show the new line), and calling the function SAPGUI_SET_FUNCTIONCODE if necessary, to get the popup B back. The only annoying thing (for user) is that the popup can be moved to another screen position, but if I call it again from A, it comes in its original position.
I didn’t check the function, whether it works in background mode (i.e. with BDC), but from its name, it looks like it’s not. Anyways, it can be very useful in some tricky situations to prevent overcomplicated processing with DYNP_VALUES_UPDATE, though the latter is the SAP-blessed way and it not difficult to use for most of tasks.