Dropdown Selection

[Former Member]

Hello everyone,

this time I am struggling with Dropdown on Dynpro.

My situation so far: one Dynpro, named BUT000-TYPE, with added Fuction Code. Yes, this one has relation to the ABAP Dictionary. When running, this Dropdown field displays all antries, as expected. Selecting any Value fires the PAI and the PBO. Also fine with my needs.

My missing link is the value of this Dropdown field at the time of PBO.

Regards,

Markus

[Former Member]

First thought.

In the PAI you have a Fields statement for your drop down field,  and that the field is defined as a global field ?

Rich

[Former Member]

I'm not quite sure if I get you right, but give me a shot.

I have tried this in my top-include: data but000-data type bu_type.

Test-coding in PBO module: txt_test = but000-data.

This one ain't working that way.

[RaymondGiuseppi]

Have you either

• coded an explicit FIELD statement in the PAI (and defined a global area field with same field name than in dynpro)
• not coded a FIELD statement, but field name is of type structurename-fieldname, and you coded a "TABLES: structurename." in the global area of the programwhere structurename is defined in ddic.

if none don't expect value to be transported to program memory...

Regards,

Raymond

[Former Member]

A couple of points.

TABLES statments are obsolete.  I generally create a type and put all my screen related fields in there,  but to be more explicit than Raymond,  in your PAI:

Process After Input.

        Fields: but000-type.

Regards

Rich

[Former Member]

OK, I think I'm with you now.

I have added this Fields-Line again at PAI.

My first attempt: global declaration
data but000-type type bu_type.

Result: blank.

My second attempt: no global declaration

Result: Compiling is not possible, error message says: "Field 'BUT000-TYPE' unknown...."

[Former Member]

Ok,

Use an underscore rather than a hyphen or:

Data: But000 Type BUT000.

In your screen,  create a field named BUT000-TYPE.  This should then cause SAP to say that it's a data dictionary field and do you want it to match.  Select yes.

Make sure that you set the field as a list box etc

In the PAI:

Process After Input.

        Fields: But000-Type.

However,  this isn't (IMHO) the correct way of doing things but still.....

Regards

Rich

[RaymondGiuseppi]

For me TABLES are not obsolete (*), the only rule is No table work areas except for classic dynpros, and yes TABLES * is obsolete, and TABLES are forbidden in classes (***)

But for me the rule is always No table work areas except for classic dynpros

In 7.40 documentation there is yet a MUST to use TABLES:

When dynpro fields are defined with reference to flat structures in ABAP Dictionary, the global data objects with the same name of the ABAP program must be declared with the statement TABLES as interface work area. Otherwise, there will be no data transport.

So either:

• code TABLES statement in global area, and FIELDS statement are optional (**)
• don't code TABLES statements, but then code explicit FIELDS statements in PAI, also global area definition required so a DATA statement (Else syntax error of course ).

Regards,

Raymond

(*) Not more obsolete in any case than classic dynpro themselves   outdated, old-fashioned, ok?

(**) But we need those (and CHAIN/ENDCHAIN) once we perform some check in PAI and keep field input available in case of error message)

(***) Still waiting to be able to [easily] create a dynpro in a class, and removing those function group associated to many classes and so also with some BAdI

[Former Member]

Hi Raymond,

For my dynpro's I use a structure,  so it migh go something like:

Types: Begin Of Main_Screen,

             field1           type xxxx,

             field2           type xxxx.

             Include          type subscreen1,  (Defined above as a struc)

Types:       OkCode           type xxxx,

       End Of Main_Screen.

I then use implicit field statements in the PAI which enables me to use chains (as you point out),  on-requests etc etc and also pass the screen contents as one variable to other routines if needed.

Regards

Rich

[RaymondGiuseppi]

Where did you use a DATA statement, else how did you prevent syntax error or dump, the target Abap field area must be available in the MODULE context?

[Former Member]

The data statement would be at global level.  Effectively the same as a Tables statement.  I also have a psychopathic abhorrence of Global data so all of my modules (both PAI and PBO) consist only of performs with parameters.  No global variable is referenced directly in a subroutine - only as a parameter.

Rich

[RaymondGiuseppi]

Do not worry, my modules too are also simple form calls with parameters. (Also easier to debug)

Also often I add the TABLES statement at start of development, but once program is finished, I remove those statements with some "DATA struct TYPE struct."

Regards,

Raymond

[Former Member]

However,  this isn't (IMHO) the correct way of doing things but still.....

I feel the same way

Anyhow, it doesn't work either. I think I will get rid of the ddict connection and rebuild this one by myself.

Regards

Markus

[Former Member]

<Do not worry,>

Heh! Bloody Cheek....  I'm, not worried   After over 30 years of programming (from machine code to high level languages),  I think I've found the most efficient way of doing things in terms of both design and maintenance at a later date!

Thanks for the discussion!

Regards

Rich

[Former Member]

Jesus, shame on me!

This shows how less I am dealing with dictionary entries on dynpros

Anyhow, the goal was:

Initialization on Top Include: DATA sel_type TYPE bu_type.

Dynpro: Naming that Dropdown Box from but000-type to sel_type.

Result: Dropdown shows all values as desired. Needless to say that access to sel_type is possible

Thanks for all your time and your input. I'm sure I will need those pieces of info in the future!

Regards

Markus