ABAP Module Pool Programming: How to make Input/Output field invisible but fillable?

[former_member611643]

Hello Gurus,

I added a label and input/output field to the screen in Screen Painter.

These components will be invisible to the user, but the input/output field will be filled from the outside (My Fiori app).

Hiding the label is not a problem (set the "Invisible" property to True), but there is a problem with the input/output field.

When I hide it, I cannot fill/populate it.

I have tried several options but without success:

1. Setting "Invisible" to True does not hide the field, but simply changes the content to an asterisk (*).
2. SCREEN-ACTIVE = '0' in the PBO hides the field but makes it unavailable for input.
3. SCREEN-INPUT = '0' the same behavior as in point #2.

I would be grateful for any useful hints/advice/feedback from your side.

Thanks

P.S. I'm not sure if that's the problem, but just in case, the label and input/output field name are the same: ZST_PAYSEND_ATTR-OUTSTD.

[sahantissera]

try the below settings.

[former_member611643]

sahan , thanks a lot for your feedback.

I need to completely hide the field. The user should never see it. In your solution, he will still see it.

[Sandra_Rossi]

I don't get the question. There's no difficulty to fill a hidden screen field by program. What is the relationship between the Fiori app and your dynpro? What is the logic to fill the dynpro field?

[former_member611643]

The program is wrapped in a transaction.

This transaction is initiated from the Fiori app and the field will only be populated with item IDs selected from that Fiori app.

[VXLozano]

What's your tool's logic?

If it's fiori "app" -> launches a transaction in background SKIPping THE FIRST SCREEN, then your program will be able to call the transaction passing the field a value.

If your fiori will just call the transaction, and leave the user with the initial selection screen, then you'll need to hide the parmeter (AND to deactivate it, or it will be visible). You can just add an ID to the parameter, and before the CALL TRANSACTION call the SET PARAMETER sentence to populate it.

[former_member611643]

This is exactly what I want to implement: the Fiori app starts/runs a transaction, passes the value to the field, and skips the initial screen.

The problem is that when the user starts/runs a transaction in the GUI (not from the Fiori app), he/she will see this field.

That's why I want to hide the field.

[matt]

Maintain two transactions - one you'll call from from the Fiori app, the other is the one for gui. Query sy-tcode to decide whether to hide the field or not. Use authorisations so that end users never get the one for the Fiori.

However...

Seeing as this appears to a z transaction, why not refactor your program, so it can do what needs to be done via a method call.

[former_member611643]

Maintaining two transactions is too redundant for this task.

[matt]

You are kidding me. It's 30 seconds work.

What you are going for is a programming solution that is >10x more expensive.

[JurgenLootens]

Hmm... I'm finding this strange.

If you don't want your users to see a field on a screen, then don't put it on the screen...

Passing a value to a field via program logic can be done by setting a parameter id or exporting the field to memory in the caller and importing it again in the called program.

Caller:

export <fieldname> from <variable> to memory id <some id>

Callee:

import <fieldname> to <variable> from memory id <some id>

Does that help?

[Sandra_Rossi]

Your question is really missing details. Even with the comments.

You are focusing on hiding via the SCREEN system table although you didn't explain how you transfer the value from Fiori app to the screen (don't you mean Fiori LaunchPad?) I didn't even understand whether your dynpro screen is a generated Selection Screen (PARAMETERS) or a General Screen.

You'd better ask a new question with all the details, because nobody understands the question enough to answer precisely.