You may need a custom tab and a subscreen exit to reproduce this problem

[Former Member]

I've got a custom tab in IW22 and a custom subscreen that's placed on this tab and processed by code in the XQQM function group.

In the PAI for the subscreen, I have code that edits a field and pops an 'E' message at the bottom of the screen if the edit fails.

Here's the problem.

I enter bad data into the field - data that I know will fail the edit.

I leave the cursor in the field, or put it in any other field of the subscreen that is open for input.

I press ENTER and everything works as it should.

But if the cursor is not in a field of the subscreen that is open for input, then NOTHING happens when I hit ENTER.

Is this standard SAP PAI/screen behavior that I just have never noticed before?

Note: I'm not talking about selection screens (1000's).

Thanks

djh

[RichHeilman]

You mentioned the PAI of the subscreen, you mean that you are handling function codes in the PAI of the subscreen and not the PAI of the main screen which implements the subscreen? IF this is the case, this may be why you are seeing this behavior. Hitting enter while your cursor is in the subscreen will surely fire the PAI of the subscreen, when the cursor is outside it, it may not. Would have to test.

Regards

RIch Heilman

[RichHeilman]

Just tested it and I kind of thought I was wrong which is now confirmed. I created a program with a subscreen with a field in it, another field in the main screen, and I put a check on the field in the subscreen. When I hit enter, with the cursor in either field, it fires the "Check" module which is in the screen flow of the subscreen.

Regards,

Rich Heilman

[former_member181923]

Rich -

I'm awarding 2 because you hit the nail on the head with respect to clarifying the problem, though not solving it.

The problem is: the "main screen" is under SAP control, not my control.

In particular:

1) Config only allows you to put subscreens of a certain size on an IW 22 custom tab.

2) There is a complex exit-handler in the SAP IW22 code (IQS0) that goes into a loop which depends on the number of subscreens you put on the custom tab in IW22;

3) the SAP code calls subscreen 1, then subscreen 2, then subscreen 3 .... then subscreen 5 (because we have five subscreens on the custom tab.)

So when enter is pressed "in" subscreen 1, control returns to the SAP program - what happens then is out of my control.

In effect, there is no "main screen" - there is just the custom tab (which is handled by the SAP code) and the subscreens on the custom tab (which are handled by my code.)

I'm going to post a blog on a related matter involving subscreen exit-handlers like the one in IW22 (where there is a dynamic control loop in the SAP code that iterates as many times as you have subscreens defined on your custom tab in config. You may be interested in reading it .. or not.

Regards

djh

[former_member181923]

Rich -

We cross posted. See my last post - the problem is - the "main screen" is out of my control in this case.

djh

[former_member181923]

Can you send me your test code anyway? I want to see if adding a specific check module to the subscreen works in this case ...

I don't see why it should - because the system is responding to ENTER properly when the cursor is in an input-enable fields ... but you never know ....

Thanks again

djh

[RichHeilman]

Put a breakpoint in the module which is being called in the PAI screen flow logic of the subscreen, like on the first statement in the module. Now run your program, try to re-create your issue again and make sure that it is not firing this module everytime, it should be.

Regards,

Rich Heilman

[RichHeilman]

Sure David, here it is. I have a field on the main screen, and another field in the subscreen 101 which is called TEST_FIELD.

Main program code.

report zrich_0001.

data:  ok_code type sy-ucomm,
       test_field type string.

start-of-selection.

  call screen 100.

************************************************************************
*      Module  STATUS_0100  OUTPUT
************************************************************************
module status_0100 output.
  set pf-status '0100'.
*  SET TITLEBAR 'xxx'.

endmodule.
************************************************************************
*      Module  USER_COMMAND_0100  INPUT
************************************************************************
module user_command_0100 input.

  case ok_code.
    when 'BACK'.
      leave program.
  endcase.

endmodule.
************************************************************************
*      Module  check_test_Field  INPUT
************************************************************************
module check_test_field input.

  if test_field is initial.
    message i001(00) with 'Hey, this field is empty'.
  endif.

endmodule.

Screen flow for screen 100.

process before output.

  module status_0100.

  call subscreen subscreen_101 including sy-repid '101'.

process after input.

  call subscreen subscreen_101.

  module user_command_0100.

Screen flow for subscreen 101.

process before output.

* MODULE STATUS_0101.

process after input.

  field test_field module check_test_field.

* MODULE USER_COMMAND_0101.

Regards.

Rich Heilman

[former_member181923]

Rich -

I don't know how much time you have to spend on this, but your example code doesn't recreate the problem as stated.

You need <b>two</b> fields on your <b>subscreen</b> - the one you're checking and another one which is not input-enabled (output only.)

After placing bad data in the field you're going to check, put the cursor on the output-only field of the subscreen.

Then press ENTER.

If the check module still fires, then I'm going to try your approach of coding an explicit check module on the field (AFTER the code has moved from DEV to QA - it's going today.)

Will let you know what happens tomorrow or this afternoon

Thanks again.

djh

[RichHeilman]

That's right, I was not able to recreate your issue with the above program, it was simply to prove me wrong, it does fire the module regardless. I will make some changes and try what you are suggesting now.

Regards,

Rich Heilman

[RichHeilman]

Again, not able to re-create your issue. ;(

Regards,

Rich Heilman

[former_member181923]

Rich - Thanks very much for double-checking. As I said, now that I've gotten that confirm from you, I will try your explicit check-field approach after the code as is moves to QA today sometime ... and will report back to you.

The reason why I think it still may not work has to do with the fact that there are "user" function codes and SAP function codes assigned to SAPMIWO0 (you can see these in SE41 if you choose SAPMIWO0 as program and select function list.

According to this list of "registered" user codes, "ENTER" is not an "approved" user-code - so SAP doesn't know to intepret as such.

But if this is the case - why does the system respond properly when the cursor is in an input enabled field, not an output only field?

Anyway ... I'll try the check-field approach and let you know ...

Thanks very much again ...

djh