Variables from selection screens

[Former Member]

Hi,

I have several selection screens building on each other. Every screen is packed in an INCLUDE structure since ABAP is telling me that selection screens are not possible within a FORM routine. That should have the same effect as if I copied the code into my main program, so using variables should not be a problem.

However, I am having sort of a circular problem using some variables I declare in that selection screen using the keyword PARAMETER: When I try to work with those variables - "outside" of the INCLUDE, back in my main program - ABAP is telling me that [variable_name] is not declared by a DATA statement - which, in fact, it isn't... When I try declaring it before the INCLUDE function, ABAP is telling me - pointing to a line in the INCLUDE - that [variable_name] is already declared... A circular problem.

Can anybody help me with that one?

Thanks a lot!

Regards,

Sapperdapper

[Former Member]

I can only guess that you put INCLUDE clause somewhere after a routine (FORM ... ENDFORM). INCLUDE that contains parameters / selection screen needs to be inserted at the very top of the program. Also I think you may need to have START-OF-SELECTION event, but am not 100% sure it's technicaly required. It's better to add it anyway though, makes the code more clear.

When you use INCLUDE it's as if you copy-paste the code into your program. There is a lot of customization we can do just with the selection screen code though. Maybe you don't even need multiple screens/INCLUDEs...

[Former Member]

Hello,

I hope you are creating a main program and including all the includes in it. If this is not working I would suggest -

Build a structured dialog program (module pool) with multiple screens.

Best Regard,

swanand

[Former Member]

Hi,

yes, I have a main program and there are multiple INCLUDE structures (all referenced into the main program), one for each selection-screen, one for all the declarations for an internal table and one for the actual SELECT.

Thanks for helping!

Best regards,

Sapperdapper

[Former Member]

Hi

The parameters of a selection-screen are just a global variable, so the point where you need to use it has to be placed after them.

It's not clear are you managed your main program, I mean where you place the include with declarations.

Max

[Jelena_Perfiljeva]

I can only guess that you put INCLUDE clause somewhere after a routine (FORM ... ENDFORM). INCLUDE that contains parameters / selection screen needs to be inserted at the very top of the program. Also I think you may need to have START-OF-SELECTION event, but am not 100% sure it's technicaly required. It's better to add it anyway though, makes the code more clear.

When you use INCLUDE it's as if you copy-paste the code into your program. There is a lot of customization we can do just with the selection screen code though. Maybe you don't even need multiple screens/INCLUDEs...

[Former Member]

Hi Jelena,

I have only INCLUDEs, no FORM routines. But there are four selection screens right now, one after the other so one can - in theory, doesn't work yet - use the variables from the last. Of course, If I could make my selection screen dynamic (with more elements appearing at the touch of a button) I might be able to assemble all my variables with just one or two.

I know that somehow I can use the AT SELECtION SCREEN event, but that's where my knowledge ends right now.

Can you help me there?

For starters, when the user enters the nr. 4 (meaning he wants to query data from four DB tables), there should be four edit_fields for the table name - depending on the nr. the user enters. Would that be doable in only one screen?

Thanks a lot!

Best regards,

Sapperdapper

[Former Member]

Hi

You should past your code, it doesn't matter if you use or don't use the includes, I mean after inserting the include in a main program, they belong to it, so it would be the same thing if you wrote all codes in the main program (so without to use the include).

Max

[Former Member]

Hi Max,

yes, I guess that would be best. Just give me a while to put together the code - I have to paste it into an editor and insert the code from the INCLUDEs in the corresponding places.

Best regards,

Sapperdapper

[Jelena_Perfiljeva]

Friedrich, please read this blog if you're interested in building a dynamic selection screen. There is also more information available on SCN and other web sites - google it.

[Former Member]

One simple way of having "dynamic" looking selection screens is to add the NO-DISPLAY option to each parameter.  Then in the AT SELECTION-SCREEN OUTPUT event code a loop at screen loop and set the screen-invisible flag off on the ones you want to show.  Like this:

AT SELECTION-SCREEN OUTPUT.

     LOOP AT SCREEN.

      CASE SCREEN-NAME.

          WHEN 'P_TBL1' OR '<p_tbl1_lablename>.     "You can discover the label name via debug or the screen painter for screen 1000.

               if p_nbr > = 1.

                    screen-invisible = '0'.

                    modify screen.

               endif.

          WHEN 'P_TBL2' OR '<p_tbl2_labelname>.

              if p_nbr >=2.

                    screen-invisible = '0'.

                    modify screen.

               endif.

       WHEN etc.....

     ENDCASE.

     ENDLOOP..

If I understand your requirements I believe this will work for you.  No need for INCLUDES at all. Just code it in the program.

[Former Member]

Hi Larry,

yes, looks like that would work, but that wouldn't do because it implies I have to code all elements that could possibly be needed - my task is to make it 100% dynamic, so I have no idea e.g. how many tables the user wants, how many fields from those etc. - I cannot prepare everything because the program will face a virtually infinite number of possibilities.

@ Jelena

Thanks. I will read it through and see what I can learn.

@ Max

Give me a while, I need to edit the comments in the code so you will understand what I meant to do - right now, the screens are hard-coded and I had to use some weird labels so ABAP wouldn't complain about my naming the same variable too often etc.

Thanks for all the help!

Best regards,

Sapperdapper

[Former Member]

Hi Jelena,

that blog is nice indeed - I can actually understand how that would work 😉 Unfortunately, what I've answered to Larry's proposal goes for this - it won't help with what I need to do. I need to make it 100% dynamic. I have realized there is lots of stuff around on the net. I will research.

@ Max

Here it is - I have decided to keep the main program and the INCLUDEs separate to give you a more accurate picture of what I've done so far. There are two files, one with the main program and one with my four INCLUDEs. I hope the comments are sufficient to point out how I'm trying to get this to work.

The dialogs are so far only "painted", they have no connection to the report running afterwards. I guess if I knew how to use the variables from one of those screens in the next, I could also use them in the report.

Thanks a lot!

Best regards,

Sapperdapper

[Former Member]

Hi

I've loaded your code and there's no sy-ntax errors, the only thing you've placed a call of a selection-screen just after the definition of the previous one, so the effect is all selection-screens will be opened in cascaded.

Max

[Former Member]

Sapperdapper,

You did not say it needed to be THAT dynamic!

You might have a look at the way SAP has written the selection screen for SE16.  Is that the way you are wanting it to work? 

I currently have a request for an application that works in a similar way, but have not found the time to develop it yet.  I was going to study SE16 to get some ideas.

However, I am thinking the INCLUDE idea may not work very well.  Maybe using field symbols would be better.

[Jelena_Perfiljeva]

There is a code sample already available on SCN for a dynamic selection screen. I have not tested it myself (never had such need), but if you Google 'dynamic selection screen' or even 'dynamic ABAP', you'll find many existing posts on the subject.

There was a great eLearning video on the old SDN on dynamic programming (ASSIGN, etc.), but I cannot find it on the new web site, unfortunately. As one of the examples it had a completely dynamic program, like SE16.

[Former Member]

Wow!, that looks awesome.  I am going to bookmark that code sample.  I have just the application for it. 

Thanks Jelena! 

[Former Member]

Hi Larry,

yes, I need to make my program that dynamic - not right away, I can take it step-wise, so maybe I can use your sample code to begin with and just allow for up to four or five tables.

I will also have a look at the way SE16 works.

Do you mean field symbols as an alternative to INCLUDEs? I am using the INCLUDEs as a means to keep my code in several bits so it can be maintained and edited, I understand field_symbols have a different purpose - though admittedly I haven't yet understood what to use them for and how exactly. That was proposed to me elsewhere, though, I believe that I have to work on understanding just how field_symbols work.

@ Jelena

That code sample does look awesome - I will try reading and understanding what it does. My primary concern is not filtering, but selecting fields to export, but I could well use a part of that logic - to enter a table name and get a clickable list of all the fields in the table. That is one part of what the user will enter in the dialog(s): The tables the user wants to export from (which then have to be joined) and the fields from them.

@ Max

Yes, the code such as it is is working - that is my "demonstration report" which I am indending to use to show what things will look like, what I intend to do. The thing is, those selection screens are static, designed so to speak "backwards" - I had the SELECT statement first, all hard-coded with four tables and filling the data into an internal table - the main part actually - and based on that (nr. of tables and fields), I designed the selection screens with fields for all the info needed.

Okay, thanks for all your help so far! I will work on understanding more of all this and working through some tutorials seems a good idea. I'll be back 😉

Best regards,

Sapperdapper

[Former Member]

Hi

Just a consideration

some sample code of dynamic selection screen (just like SE16) need to regenerate the program, so in this case you need to prevent a dump, if several users run the program at the same time.

Max

[Former Member]

Hi Max,

that's not a problem - or rather, it won't be my concern until far in the future when I have the program up and running. In all probability, there will be only a handful of users authorized to use this - the current scenario I'm building this for is HR tables - and only one user at a time.

Thanks anyway for mentioning!

Best regards,

Sapperdapper

[Former Member]

Hi Larry,

I'm again reading about field_symbols and it seems they are just what I need: If I understand correctly, I can write ABAP statements using field_symbols and at runtime, those will be "filled with" some value, no?

So, I could e.g. write a SELECT <fs1> FROM <fs2> statement and assign to that <fs> the value from some dialog_field - so that, given the user enters the table name 'KNA1' and the field name 'KUNNR' in the dialog, that will execute as
>SELECT KUNNR FROM KNA1<

Is that right? In my large "ABAP reference" book, there's just two pages on them, so it must be real simple. That's what I want to do actually - the user will enter a lot of table and field names in the dialog(s) and I want to use those (as pointers to existing DB objects) in the actual report program.

Thanks a lot!

Best regards,

Sapperdapper

[Former Member]

Hi

The field-symbol is just a pointer to a certain memory area, so a variable.

That means you need to use it as work-area, but before you have to define (assign it).

PARAMETERS: P_TABNAME(30) TYPE C.

DATA: W_DYN TYPE REF TO DATA.

FIELD-SYMBOLS: <FS_WA> TYPE ANY.

CREATA DATA W_DYN TYPE (P_TABNAME).

ASSIGN W_DYN->* TO <FS_WA>.

SELECT * INTO <FS_WA>

  FROM (P_TABNAME).

You can also (see the help) a internal table in order to define the WHERE conditions:

SELECT * INTO <FS_WA>

  FROM (P_TABNAME)

     WHERE (TAB_WHERE).

But in the internal table for the conditions it can't use the select-options.

Max

[Former Member]

Hi Max,

thanks a lot! I think that goes a long way towards what I need.

I'll use the code such as it is (about table names) too, but even before that, I need to declare my internal table and make sure the fields there have the correct datatype so the fields I'm going to SELECT from various joined DB tables will "fit into" those fields.

What I have made of your code so far is the following:

DATA: Field8 TYPE C LENGTH 5 VALUE 'ERDAT'.

[[Field8 is one of the variables that should be coming from my dialog(s).]]

DATA W_DYN TYPE REF TO DATA.

FIELD-SYMBOLS: <FS_Datefld>.

CREATE DATA W_DYN TYPE (Field8).

[[ERDAT has datatype 'D', so I need the field to have that datatype so my SELECT will work]]

ASSIGN W_DYN->* TO <FS_Datefld>.

After that, I have the regular four-step declaration of an internal table itab01, the first step being the declaration of the linetype:

TYPES: BEGIN OF zeile01_typ,

          KUNNR TYPE STRING,

...

...

          ERDAT LIKE <FS_Datefld>,

       END OF zeile01_typ.

Now, the field I call ERDAT (which is just that same variable from the dialog) should have datatype D.

I have tried several permutations of the type_declaration with TYPE and LIKE and REF TO, but ABAP is telling me that <FS_Datefld> has no datatype or it's telling me something about datatype C (which I do not want here anyway) being forbidden.

Can you help me out here please?

Thanks a lot!

Best regards,

Sapperdapper

[Former Member]

Hi

TYPES: BEGIN OF zeile01_typ,

          KUNNR TYPE STRING,

...

...

          ERDAT LIKE <FS_Datefld>,

       END OF zeile01_typ.

You can't use that defination, in this case you should use the classes CL_ABAP_ * in order to define a structure (or an internal table) at runtime.

In this situation u can try to define all you need to dynamically, see this sample:

DATA P_TABLE TYPE  DDOBJNAME VALUE 'KNA1'.

DATA: DFIES_TAB  TYPE STANDARD TABLE OF DFIES WITH HEADER LINE.

DATA: BEGIN OF T_FIELDS OCCURS 0,

        FLD TYPE DFIES-FIELDNAME,

       END   OF T_FIELDS.

DATA: LR_VALUE_DESCR  TYPE REF TO CL_ABAP_ELEMDESCR, "Single element

       COMPONENT       TYPE CL_ABAP_STRUCTDESCR=>COMPONENT.

DATA: FIELD_LEN       TYPE I.

*

DATA: LT_COMPONENTS   TYPE CL_ABAP_STRUCTDESCR=>COMPONENT_TABLE. "Field structure

DATA: TYPE_STRUCT     TYPE REF TO CL_ABAP_STRUCTDESCR.

DATA: TYPE_TAB        TYPE REF TO CL_ABAP_TABLEDESCR.

*

DATA: DYN_TAB         TYPE REF TO DATA.

FIELD-SYMBOLS: <FS_TAB> TYPE TABLE.

FIELD-SYMBOLS: <FS_WA> TYPE ANY.

START-OF-SELECTION.

* Get table fields

   CALL FUNCTION 'DDIF_FIELDINFO_GET'

     EXPORTING

       TABNAME   = P_TABLE

     TABLES

       DFIES_TAB = DFIES_TAB.

* Get some fields for selection

   LOOP AT DFIES_TAB

      WHERE FIELDNAME = 'KUNNR'

         OR FIELDNAME = 'ERDAT'

         OR FIELDNAME = 'NAME1'.

     MOVE  DFIES_TAB-INTLEN TO FIELD_LEN.

* Create single field:

* Name:

     COMPONENT-NAME = DFIES_TAB-FIELDNAME.

* Type

     CASE DFIES_TAB-INTTYPE.

       WHEN 'C'. "Char

         MOVE CL_ABAP_ELEMDESCR=>GET_C( P_LENGTH = FIELD_LEN )

           TO LR_VALUE_DESCR.

       WHEN 'D'. "Date

         MOVE CL_ABAP_ELEMDESCR=>GET_D( ) TO LR_VALUE_DESCR.

       WHEN OTHERS. "Check class for others types

     ENDCASE.

     COMPONENT-TYPE = LR_VALUE_DESCR.

     INSERT COMPONENT INTO TABLE LT_COMPONENTS.

* Set fields for selec

     T_FIELDS-FLD = DFIES_TAB-FIELDNAME.

     APPEND T_FIELDS.

   ENDLOOP.

* Define a structure dynamically:

   TYPE_STRUCT = CL_ABAP_STRUCTDESCR=>CREATE( P_COMPONENTS = LT_COMPONENTS

                                          P_STRICT     = 'X' ).

* Define an internal table based on structure

   TYPE_TAB = CL_ABAP_TABLEDESCR=>CREATE( P_LINE_TYPE = TYPE_STRUCT ).

* Create table

   CREATE DATA DYN_TAB TYPE HANDLE TYPE_TAB.

   ASSIGN DYN_TAB->* TO <FS_TAB>.

* Do selection

   SELECT (T_FIELDS) UP TO 10 ROWS INTO TABLE  <FS_TAB>

      FROM (P_TABLE).

   LOOP AT <FS_TAB> ASSIGNING <FS_WA>.

     WRITE: / <FS_WA>.

   ENDLOOP.

Max

[Clemenss]

Hi Friedrich,

if you syntax-check a source where global variables (such as parameters or  select-options) are used that are declared somewhere else, you must check the main program (Ctrl-F7).

Create the program with a TOP-Include. Put all global declarations together with all selection-screen includes (or source lines) into TOP include.

Main program should just have the events required: INITIALIZATION and AT SELECTION-SCREEN events if needed, START-OF-SELECTION. END-OF-SELECTION is never really needed except for structuring purposes.

Regards,

Clemens

[former_member703985]

Hi Friedrich,

While Activating include, you can get pop message 'Error During Activation'. If you Click 'Activate Anyway' option (means forcibly activating), you wont get such Error message Again. Even when before Include also (in main program) we can apply the same option, it works. Try this!

Regards

Kishore

[Former Member]

Hi all,

I'll close this and mark it as "Assumed answered". Building selection screens is no longer a requirement for myself - it actually never was, that's a long story. My colleague has already programmed an awesome GUI, I just have to feed the appropriate data into it and lateron use the data coming out of it.

Thanks for all the help!

Best regards,

Sapperdapper