Attach script to multiple screens of an application

[pokrakam]

Is is possible to use a script in multiple screens of a transaction without making it global?

My scenario is with the EWM RF scanning, transaction /SCWM/RFUI. It is built using a dynamic outer screen that provides header and footer, and renders the main application data in subscreens.

Challenge one was to know what screen I'm on, as everything is on screen 1 and the subscreen number is not available in the script. Easy enough by testing existence of a field particular to a subscreen.

Challenge two is where I'm struggling: It will switch the outer screen depending on display mode and other factors, such as showing or hiding an error bar, all the while rendering the same subscreen in the middle. Local scripts are however only attached to one screen.

So for example, it starts off with Screen 1, and I added some scripts. But if an invalid number is entered, it will switch to screen 2 which includes an error message field at the bottom and still includes the same subscreen in the middle. But this means now my scripts are no longer available. At first I was tearing my hair out and ready to raise it with SAP, until I figured out the secret screen switch. So the user sees one behaviour, but if s/he enters something wrong and corrects it then the scripting is no longer there and results in an ugly error popup.

There's a nice document that describes how to Persona-fy the Mobile RF apps, but their examples run into the same issues. The only two options I can think of is to duplicate scripts to all screens (6 of them), which is not good for maintenance, or to make every EWM script global, which I think is a bit much. Are there better alternatives?

[kmagons]

Hi mike.pokraka,

All flavor local scripts are bound to a specific context defined by a t-code, application and screen. Re-using a local script across different contexts is not supported. Therefore, you have to create a global script that can be then assigned to events in different contexts.

If you need to determine the active screen number in a global script, you can leverage the session.info.screenNumber API method to implement branching based on the active screen.

Hope, this helps.

Best regards,

Krists Magons

SAP Screen Personas Dev Team

[pokrakam]

Thanks kmagons,

That's the sensible approach. However EWM RF works inside out. It is for handheld devices (e.g. barcode scanners) and an application typically consists of several pages with just a handful of data at a time.

Each of these pages is a subscreen and I'm trying to customise these. So the subscreen is the "real" application, and the screen number changes dynamically depending on device and whether a message is shown or how many buttons should be visible.

e.g. For delivery processing I may be on screen 0001 (without message) subscreen 301 and enter an invalid delivery number.
The system now switches to screen 0002 (which includes a message line) still on subscreen 301.

I correct the input and it will move on to the goods receipt, which is screen 0001 subscreen 401.
Same thing happens if a message is displayed it will use screen 0002 subscreen 401. Or it may be screen 0003 subscreen 401 on a different device.

So screen number is irrelevant in this environment, as my adaptation is based on the subscreen. It is a little irksome to make a global script for just one transaction, but without subscreen knowledge inside the script that becomes an even uglier hack.

Thanks & regards,
Mike

[Ritz]

mike.pokraka,,

Thanks for sharing.

If its running on "oN-load" It will also run on non-relevant screen's too, doesn't it affect performance?

you are right, "session.screen.subScreenNumber" would have been very handy.

Thanks

RD

[pokrakam]

Hi ritesh.dube,

Yes, it would, but as these screens are very simple pages (8x40 characters for the standard one), I don't imagine anywhere near as much impact as a full blown ME23N. It will check existence within 4-10 fields at most and be done.

[Ritz]

mike.pokraka,

Thanks for posting it as now I know I am not alone here 🙂

Due to this 2nd error screen we also need to adopt screen changes (buttons, fonts, fields etc) we made for main screen.

So far, I am living with creating local scripts twice with screen validations.

Thanks

RD

[pokrakam]

Hi ritesh.dube ,

Thanks for your input. FWIW, for my scenario I've revised my approach: Originally I had several functionalities neatly packaged into local scripts, each one performing one thing. Now I have a large global script for all onLoad events and another for all onEnter. These contain everything in if / switch branches.

I don't like having to do existence check on a field to identify a screen, as it could appear in multiple screens. It would be nice if we had something like session.screen.subScreenNumber