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?
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.
Related
My task is to customize the Header Details Screen of the ME33K transaction, the goal is to add a box with new fields that should appear only if the Agreement type is the one I defined by using the transaction SPRO (ex: Agreement type ABC).
I started making an enhancement to that screen by using the CMOD transaction, I created a dummy box and field with some hard-coded input value and it's working fine.
My next step would be to make these new fields appear only if the Agreement is of type ABC, but I cannot find the correct approach.
I tried doing some Screen-Loop programming and deactivating the box and/or fields, but the only ones that get deactivated are the standard ones that exist already, the ones I added with the enhancement are not affected.
EDIT :
The enhancement I used was 'MM06E005'.
I wrote the following Screen-Loop code in the include provided in the 'EXIT_SAPMM06E_006' user exit :
loop at screen.
if screen-name = 'CUSTOM_FIELDS'.
screen-active = 0.
modify screen.
endif.
endloop.
The enhancement MM06E005 refers to the subscreen SAPLXM06 0101, that you have created with a box with all your custom screen fields.
To hide your custom screen fields, you must:
Call a PBO (Process Before Output) module, to be done in the flow logic of your subscreen (the one which contains the screen fields):
PROCESS BEFORE OUTPUT.
...
MODULE modify_screen_field_attributes.
...
PROCESS AFTER INPUT.
...
In the include LXM06O01 (preferrably), do this:
MODULE modify_screen_field_attributes OUTPUT.
LOOP AT SCREEN.
IF screen-name = 'CUSTOM_FIELDS'. " name of one screen field
screen-active = 0. " hide the screen field
MODIFY SCREEN.
ENDIF.
ENDLOOP.
ENDMODULE.
After selecting a value in a dropdown listbox field, there is this error message:
Entry is too long for the field
(it's the message number 00092)
I created one text field TXTOPENV as Listbox with key value, set value using VRM_SET_VALUES in PBO section.
Here is the screenshot of screen painter:
Screen flow logic:
PROCESS BEFORE OUTPUT.
MODULE status_0210.
ABAP code:
DATA txtopenv TYPE c LENGTH 1.
MODULE status_0210 OUTPUT.
SET PF-STATUS 'ST210'.
SET TITLEBAR 'T210'.
PERFORM GetVacancy.
ENDMODULE.
FORM GetVacancy.
TYPES: BEGIN OF ty_vacancy,
plans TYPE t528t-plans,
plstx TYPE t528t-plstx,
END OF ty_vacancy.
DATA: wa_vacancy TYPE ty_vacancy.
LOOP AT it_vacancyid INTO wa_vacancyid.
SELECT plans plstx
FROM t528t
INTO wa_vacancy
WHERE plans = wa_vacancyid-ty_objid.
ENDSELECT.
field_id = wa_vacancy-ty_plans.
value = wa_vacancy-ty_plstx.
APPEND value TO values.
CLEAR wa_vacancy.
ENDLOOP.
CALL FUNCTION 'VRM_SET_VALUES'
EXPORTING
id = 'TXTOPENV'
values = values
EXCEPTIONS
id_illegal_name = 1
OTHERS = 2.
ENDFORM.
The error "Entry is too long for the field" is not specifically related to the listbox fields, but may occur with all types of screen fields, so I will first answer the general case, and then explain why you were mistaken .
The error happens when the screen field is defined with a "definition length" which is larger than the length defined for the eponym global variable in the ABAP program (eponym: the name has to be the same so that to allow the transfer of values between screen and program, back and forth), and when the input value is larger than the length of the ABAP program.
In your case, the key of the selected value in the listbox is probably larger than 1 character which is the length of the global variable.
The solution in your case is to set the variable to 8 characters:
DATA txtopenv TYPE t528t-plstx.
NB:
In your screenshot of the listbox field with possible values, only the texts are shown, but you can also display the key value via SAP GUI settings Interaction Design > Visualization 1 > Show keys within dropdown lists.
I have the following program.
REPORT zz_tab_strip_obligatory.
SELECTION-SCREEN BEGIN OF TABBED BLOCK tab FOR 20 LINES.
SELECTION-SCREEN TAB (54) tab1 USER-COMMAND tab1 DEFAULT SCREEN 100.
SELECTION-SCREEN TAB (54) tab2 USER-COMMAND tab2 DEFAULT SCREEN 200.
SELECTION-SCREEN END OF BLOCK tab.
SELECTION-SCREEN BEGIN OF SCREEN 100 AS SUBSCREEN.
PARAMETERS:
p1 TYPE i.
SELECTION-SCREEN END OF SCREEN 100.
SELECTION-SCREEN BEGIN OF SCREEN 200 AS SUBSCREEN.
PARAMETERS:
p2 TYPE i OBLIGATORY.
SELECTION-SCREEN END OF SCREEN 200.
INITIALIZATION.
tab1 = 'Tab1'.
tab2 = 'Tab2'.
The first tab has no obligatory fields. The second one on the other hand does.
The problem I am having is that if the user does not go to the second tab and instead of it starts the program immediately with F8 then the obligatory check for the parameters p2 is not performed at all. It looks like all of the events like AT SELECTION-SCREEN are executed only for the current tab ergo for the displayed subscreen.
Is there any way to work around it? My current solution right now is sadly getting rid of OBLIGATORY keywords and making the checks after START-OF-SELECTION (my real program has many tabs).
I do not think there is a direct solution to the selection screen obligatory issue. Here is a similar topic. However, you can store all the obligatory parameters in an internal table. At the Start-of-selection, loop through them and check them.
DATA: BEGIN OF gt_obl_fields OCCURS 0,
fname TYPE char10,
ftext type char50,
END OF gt_obl_fields.
INITIALIZATION.
tab1 = 'Tab1'.
tab2 = 'Tab2'.
gt_obl_fields-fname = 'P2'.
gt_obl_fields-ftext = text-001.
APPEND gt_obl_fields.
"...
START-OF-SELECTION.
LOOP AT gt_obl_fields .
ASSIGN (gt_obl_fields-fname) TO FIELD-SYMBOL(<fs_field>).
IF <fs_field> IS ASSIGNED AND <fs_field> IS INITIAL..
CONCATENATE gt_obl_fields-ftext 'field must be filled!' INTO data(lv_message).
MESSAGE lv_message TYPE 'E'.
ENDIF.
ENDLOOP.
I have a screen with one table control which displayed values from my internal db.
It worked out flawlessly.
I added another table control which didn't worked out the way i wanted.
I deleted the control CONTROLS: tc_two TYPE TABLEVIEW USING SCREEN 9000.
And now I'm getting a runtime error CONTROL-Variable not found.
Q: What happens if i declare new Controls? Where do they get implemented?
I tried to debug my code and the error appears at CALL SCREEN 9000.
Here is the full code:
REPORT zsch_test.
CONTROLS: tc_one TYPE TABLEVIEW USING SCREEN 9000.
DATA: it_uebung TYPE TABLE OF zsch_uebung,
ok_code TYPE sy-ucomm,
fill TYPE i.
TABLES zsch_uebung.
DATA: lines TYPE i,
limit TYPE i.
SELECT * FROM zsch_uebung INTO CORRESPONDING FIELDS OF TABLE it_uebung WHERE status = '1'.
CALL SCREEN 9000.
MODULE status_9000 OUTPUT.
SET PF-STATUS 'STATUS9000'.
* SET TITLEBAR 'xxx'.
DESCRIBE TABLE it_uebung LINES fill.
tc_one-lines = fill.
ENDMODULE.
MODULE fill_table_control OUTPUT.
READ TABLE it_uebung INTO zsch_uebung INDEX tc_one-current_line.
ENDMODULE.
MODULE cancel INPUT.
LEAVE PROGRAM.
ENDMODULE.
MODULE read_table_control INPUT.
lines = sy-loopc.
MODIFY it_uebung FROM zsch_uebung INDEX tc_one-current_line.
ENDMODULE.
MODULE user_command_9000 INPUT.
ok_code = sy-ucomm.
CASE ok_code.
WHEN 'EXIT'.
LEAVE PROGRAM.
WHEN OTHERS.
ENDCASE.
ENDMODULE.
Screen 9000:
PROCESS BEFORE OUTPUT.
MODULE STATUS_9000.
LOOP WITH CONTROL TC_ONE.
MODULE fill_table_control.
ENDLOOP.
PROCESS AFTER INPUT.
MODULE cancel AT EXIT-COMMAND.
LOOP WITH CONTROL TC_ONE.
MODULE read_table_control.
ENDLOOP.
MODULE USER_COMMAND_9000.
Thanks!
sadly it's in german
From the fact that the problem disappeared apparently without further action, one might assume that this was either a buffer issue (which is why you should re-start the entire transaction when testing a changed program) or you accidentally failed to activate the entire program (and, for example activated only the report source, but not the screen definition).
Suppose I have a selection-screen block with two parameters. I want to dynamically fill the second parameter based on what the user inputs in the first, for instance by querying a table to find the expected value for the key field in parameter 1.
As an example, say I have a program that does something for a combination of order number (p_aufnr) and WBS element (p_wbs). Instead of asking the user to provide both, I can determine one of them from the PSPEL field on the AUFK table. However, I still want to show this field to the user after he inputs his order number so he can verify that the WBS element is correct.
I've managed to do this by using the AT SELECTION SCREEN ON p_aufnr event to assign a value to p_wbs. This event is processed when the user presses enter. However, I can only ever get it to work once. So if the user enters an order number, realises from the retrieved WBS element that he made a mistake and changes it, the second parameter never changes. Even though the AT SELECTION SCREEN event is processed in the debugger, the parameter is not updated.
Am I not supposed to use this event for my scenario? If so, how would I then implement this sort of dynamic selection screen?
Forgot to add a code sample. The following report illustrates my issue: after entering a value in p_netw and pressing enter, p_wbs is filled with the value 1. However, if you press enter again the AT SELECTION-SCREEN ON routine is processed but the value for p_wbs is not updated, while lv_count is.
DATA: lv_count TYPE i.
SELECTION-SCREEN BEGIN OF BLOCK main.
PARAMETERS: p_netw TYPE aufnr OBLIGATORY MODIF ID auf.
PARAMETERS: p_wbs TYPE i MODIF ID psp.
SELECTION-SCREEN END OF BLOCK main.
AT SELECTION-SCREEN ON p_netw.
ADD 1 TO lv_count.
p_wbs = lv_count.
START-OF-SELECTION.
PERFORM main.
FORM main.
WRITE: 'The value reached ', lv_count.
ENDFORM.
Apparently the data is not written back to the screen if you update the field in the field-specific block. If you move the field update from AT SELECTION-SCREEN ON p_netw to the global AT SELECTION-SCREEN event, it works. Don't ask me why, though - this seems to a case of undocumented system behaviour...
DATA: lv_count TYPE i.
SELECTION-SCREEN BEGIN OF BLOCK main.
PARAMETERS: p_netw TYPE aufnr OBLIGATORY MODIF ID auf.
PARAMETERS: p_wbs TYPE i MODIF ID psp.
SELECTION-SCREEN END OF BLOCK main.
AT SELECTION-SCREEN ON p_netw.
ADD 1 TO lv_count.
AT SELECTION-SCREEN.
p_wbs = lv_count.
You need to use a PAI (process after input) module on your screen which then takes the new p_aufnr and finds the appropriate p_wbs - probably exactly like your at selection screen event. You will then CALL SCREEN ### <-- your screen number to display the data on your screen. Without any code to work off thats all i can help with.