08-25-2015 9:35 AM
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
08-25-2015 12:47 PM
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
08-25-2015 1:01 PM
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.
08-25-2015 1:06 PM
Have you either
if none don't expect value to be transported to program memory...
Regards,
Raymond
08-25-2015 1:14 PM
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
08-25-2015 1:34 PM
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...."
08-25-2015 1:42 PM
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
08-25-2015 2:03 PM
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:
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
08-25-2015 2:13 PM
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
08-25-2015 2:34 PM
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?
08-25-2015 2:40 PM
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
08-25-2015 2:50 PM
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
08-25-2015 2:53 PM
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
08-25-2015 2:53 PM
<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
08-25-2015 3:11 PM
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