Radiobutton runtime error in selection screen with dynamic visibility

Question

When setting up a selection screen with dynamic visibility of the controls I ran into an unexpected runtime error DYNP_TOO_MANY_RADIOBUTTONS_ON . Reduced sample code to the following reproducible example:

REPORT ztest1.

SELECTION-SCREEN BEGIN OF BLOCK category.
PARAMETER:
  rb_cata   RADIOBUTTON GROUP cat USER-COMMAND selection_changed DEFAULT 'X',
  rb_catb   RADIOBUTTON GROUP cat.
SELECTION-SCREEN END OF BLOCK   category.
SELECTION-SCREEN BEGIN OF BLOCK action.
PARAMETER:
  rb_act1   RADIOBUTTON GROUP act USER-COMMAND selection_changed DEFAULT 'X' MODIF ID act,
  rb_act2   RADIOBUTTON GROUP act.
SELECTION-SCREEN END OF BLOCK   action.

AT SELECTION-SCREEN OUTPUT.
  LOOP AT SCREEN.
    CASE screen-group1.
      WHEN 'ACT'.
        screen-invisible  = COND #( WHEN rb_cata = abap_true THEN 0 ELSE 1 ).
      WHEN OTHERS.
    ENDCASE.
    MODIFY SCREEN.
  ENDLOOP.

When selecting rb_catb and then re-selecting the first radiobuttion I get the runtime error DYNP_TOO_MANY_RADIOBUTTONS_ON with comment:

In a group of radio buttons, exactly one of the fields must be set - meaning that must have the value 'X'. If this is not the case, one of the following situations occurs: - Multiple radio buttons of the group are set at the same time. This error causes the appplication to terminated and triggers the short dump that you are currently reading.

But I'm only changing the visibility of the buttons, why am I getting an error relating to the actual active status?

Answer 1

The reason for this is a failure to set the exact same MODIF ID on all buttons in the radiobutton group . While the precise screen processing logic is hard to get at, it appears that all elements in the radiobutton group (RBG) need to be changed at the same time to avoid processing issues. So in the above example:

rb_act1   RADIOBUTTON GROUP act USER-COMMAND selection_changed DEFAULT 'X' MODIF ID act,
rb_act2   RADIOBUTTON GROUP act MODIF ID act.

I initially suspected issues with the ACTIVE or INVISIBLE attributes conflict but those appear unrelated. The actual reason these controls need to change in lockstep is unknown without being able to look at the screen processing logic that's likely hidden in the kernel. Note that the MODIF ID has to be the exact same, any mixing of these IDs within a single RBG will result in this runtime error.