Dropdown list in dialog programming

Moved to correct forum by moderator. Subject amended. Please use meaningful subjects in future
Hi Experts,
How to get a drop down list in Dialog Programming. I need a drop down list for a field called country. Should it be done in Layout Editor or in the coding part. If at coding part can you please help me out with some pointers?
TIA
Edited by: Matt on Nov 16, 2008 4:11 PM

SELECTION-SCREEN BEGIN OF SCREEN 111 AS SUBSCREEN.
SELECTION-SCREEN BEGIN OF LINE.
SELECTION-SCREEN COMMENT 5(11) text-012 FOR FIELD p_step1 MODIF ID st1.
PARAMETER: p_step1 TYPE c AS LISTBOX VISIBLE LENGTH 20
                   USER-COMMAND step1 OBLIGATORY MODIF ID st1.
SELECTION-SCREEN END OF LINE.
SELECTION-SCREEN END OF SCREEN 111.
DATA: name1 TYPE vrm_id,
       list1 TYPE vrm_values,
       value1 LIKE LINE OF list1.
IF list1[] IS INITIAL.
    name1 = P_STEP1.
    value1-key = 1.
    value1-text = your text which you want to display in the list.
    APPEND value1 TO list1.
    value1-key = 2.
    value1-text = your text which you want to display in the list.
    APPEND value1 TO list1.
    CALL FUNCTION 'VRM_SET_VALUES'
      EXPORTING
        id              = name1
        values          = list1
      EXCEPTIONS
        id_illegal_name = 1
        OTHERS          = 2.
ENDIF.

Similar Messages

Dropdown List in report program

Hi
Anybody send me the Dropdown list coding for a parameter in s selection-screen of a normal report program without using a module-program
regards
paul

HI paul
try this
TYPE-POOLS: VRM.
TABLES SPFLI.
TABLES SSCRFIELDS.
DATA flag.
DATA: NAME TYPE VRM_ID,
      LIST TYPE VRM_VALUES,
      VALUE LIKE LINE OF LIST.
PARAMETERS PS_PARM LIKE SPFLI-CARRID AS LISTBOX VISIBLE LENGTH 10
USER-COMMAND
fcodex.
data: i_spfli type spfli occurs 0 with header line.
PARAMETERS PQ_PARAM LIKE SPFLI-connid AS LISTBOX VISIBLE LENGTH 15
USER-COMMAND
fcodey.
*DS AS CHECKBOX USER-COMMAND FLAG.
INITIALIZATION.
NAME = 'PS_PARM'.
DATA T TYPE I VALUE 0.
SELECT DISTINCT carrid into corresponding fields of table i_spfli FROM
SPFLI.
loop at i_spfli.
    VALUE-KEY = i_spfli-CARRID.
    VALUE-TEXT = i_spfli-CARRID.
    APPEND VALUE TO LIST.
endloop.
CALL FUNCTION 'VRM_SET_VALUES'
    EXPORTING
      ID     = NAME
      VALUES = LIST.
AT SELECTION-SCREEN.
if sy-ucomm eq 'FCODEX'.
    REFRESH LIST.
    CLEAR LIST.
    PQ_PARAM = ' '.
    NAME = 'PQ_PARAM'.
    SELECT * FROM SPFLI WHERE CARRID = PS_PARM.
      VALUE-KEY = SPFLI-connid.
      VALUE-TEXT = SPFLI-connid.
      APPEND VALUE TO LIST.
    ENDSELECT.
endif.
AT SELECTION-SCREEN OUTPUT.
LOOP AT SCREEN.
    IF SY-UCOMM NE 'FCODEX' OR SY-UCOMM NE 'FCODEY'.
      CALL FUNCTION 'VRM_SET_VALUES'
        EXPORTING
          ID     = NAME
          VALUES = LIST.
      MODIFY SCREEN.
    ENDIF.
ENDLOOP.
START-OF-SELECTION.
clear i_spfli.
refresh i_spfli.
select * into table i_spfli from spfli where carrid = ps_parm and connid
= pq_param.
loop at i_spfli.
    WRITE: / 'CITY FROM:', I_SPFLI-CITYFROM, 'CITY TO :',I_SPFLI-CITYTO,
   'DEPARTURE TIME :', I_SPFLI-DEPTIME.
regards
kishore
Message was edited by: Harikishore Sreenivasulu

Declaring constant data in a list box - Dialog programming

i need to declarare some constant data 1...4 in list box in dialog programming i have done some coding its not working here is the code, can you plz tell me whats wrong in the code non of the values are displaying in drop downbox.
type-pools vrm.
DATA: name TYPE vrm_id,
list TYPE vrm_values,
value LIKE LINE OF list.
clear list.
REFRESH LIST.
value-key = '1'.
value-text = 'Sales & Distribution'.
append value to list.
value-key = '2'.
value-text = 'Material Management'.
append value to list.
value-key = '3'.
value-text = 'Finance & Controlling'.
append value to list.
CALL FUNCTION 'VRM_SET_VALUES'
EXPORTING
 id = 'LISTBOX1'
 values = list
EXCEPTIONS
ID_ILLEGAL_NAME = 1
OTHERS = 2
IF sy-subrc <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
 WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.

I think your code is correct onlybut the problem may be where
you are passing the internal table to the FM 'VRM_SET_VALUES' ...
Try to use the following code..
CALL FUNCTION 'VRM_SET_VALUES'
EXPORTING
id = 'LISTBOX1'
values = list[]

Dropdown list in module pool program

Hi,
I need to display a dropdown list for LFA1-LIFNR in my module pool program.
In the screen painter I have added an Input/Output field with name LFA1-LIFNR and corresponding to the Dropdown option I have selected Listbox. When I execute the program empty dropdown list is coming. It is not taking the values of LIFNR from the table LFA1. Please let me know the solution for this.
Thanks,
Neethu.

Hello Abaper,
You have very well designed the drop-down box that is to be reflected in your program. The next thing for you to do is use any 1 method for populating the values i.e. using the function module F4IF_INT_TABLE_VALUE_REQUEST or VRM values. I prefer to use the the F4IF_INT_TABLE_VALUE_REQUEST as it is easy to use and understand. If you use the following function module then you need to call in a module under the flow logic of the screen i.e. PROCESS ON VALUE REQUEST.
Let me just illustrate you with the syntax -
Module Pool Code
*internal table declaration
TYPES : BEGIN OF ty_lifnr,
                 lifnr TYPE lfa1-lifnr,
END OF ty_lifnr.
DATA : itab_lifnr TYPE STANDARD TABLE OF ty_lifnr.
*Dialog Modules for PBO
*Dialog Module for PAI
MODULE cancel INPUT.
   LEAVE PROGRAM.
*Dialog Module Process on value reuest
MODULE create_dropdownbox INPUT.
   SELECT lifnr
   FROM LFA1
   INTO CORRESPONDING FIELDS OF TABLE itab_lifnr.
CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'
   EXPORTING
         retfield      = 'LIFNR'
         value_org = 'S'
   TABLES
         value_tab = itab_lifnr
   EXCEPTIONS
ENDMODULE.
Now for the Flow Logic -
PROCESS BEFORE OUTPUT.
PROCESS AFTER INPUT.
   MODULE cancel AT EXIT-COMMAND.
   MODULE user_command_0100.
PROCESS ON VALUE REQUEST.
   FIELD lfa1-lifnr MODULE create_dropdownbox.
Hope this helps ! Let me know if any other doubts arises.

Handle text using list box in dialog program

hi,
I am working on dialog program , Created two fileds , one is list box type I/O field and another is i/O field which displays text based on value selected in list box.
Please provide any inf how to Handle text using list box value in dialog program.
thanks

Hi,
<li>Check the screen to know how to set I/O field to set as listbox.[ dropdown box picture|http://2.bp.blogspot.com/_O5f8iAlgdNQ/Sm7RBrqfjcI/AAAAAAAAFaU/RateViiVqrU/s1600-h/drop_down-754481.JPG]
<li>in the above screen we need to set FctCode for the dropdown box field so that when you select value from the dropdown box PAI event is triggered.
<li>screen flow logic like below
PROCESS BEFORE OUTPUT.
MODULE values_into_dropdown.
FIELD g_bukrs.
FIELD g_text.
PROCESS AFTER INPUT.
FIELD g_bukrs.
FIELD g_text MODULE get_bukrs_txt.
<li>Logic to fill Dropdown field with values.
PROGRAM sapmztest_dropdown.
DATA: g_bukrs TYPE t001-bukrs.
*& Module VALUES_INTO_DROPDOWN OUTPUT
MODULE values_into_dropdown OUTPUT.
TYPE-POOLS:vrm.
DATA:
 field TYPE vrm_id,
 it_values TYPE vrm_values,
 wa_values LIKE LINE OF it_values.
DATA: t001 TYPE t001 OCCURS 0 WITH HEADER LINE.
IF it_values[] Is INITIAL.
 SELECT * FROM t001 INTO TABLE t001 UP TO 10 ROWS.
 LOOP AT t001.
 wa_values-key = t001-bukrs.
 wa_values-text = t001-butxt.
 APPEND wa_values TO it_values.
 CLEAR wa_values.
 ENDLOOP.
ENDIF.
field = 'G_BUKRS'.
CALL FUNCTION 'VRM_SET_VALUES'
 EXPORTING
 ID = FIELD
 values = it_values.
ENDMODULE. " VALUES_INTO_DROPDOWN OUTPUT
*& Module get_bukrs_txt INPUT
MODULE get_bukrs_txt INPUT.
read table it_t100 into wa_t100 with key bukrs = g_bukrs.
g_text = t001-butxt.
ENDMODULE. " VALUES_INTO_DROPDOWN INPUT
I hope that it helps you.
Thanks
Venkat.O

Passing Values to a dropdown list within a dialog box

I am using the app.execDialog(dialog1) command to display a dialog box on my form. The dialog box contains dropdown list (popup). I have found examples that do this but in all the examples they reference the loadDefaults function with hardcoded values.
For example:
loadDefaults: function (dialog)
dialog.load(
subl:
"Acrobat Standard": "111",
"Adobe Reader": "222"
Does anyone know if there is a way to pass values into the loadDefaults via a variable etc.. I can get the data I want to populate the dropdown with but I cant figure out how to load it into the control.
Thanks
Ken

Hi scamp, not sure what you're asking. What do you mean by "pass" fields from one list to another? If you need information in list 1 to show in list 2, just create lookup columns in the SharePoint list. If you mean you want to add columns to
list 2 automatically, you'll need to make a designer workflow for that.
cameron rautmann

Dialog program that lists an ALV Grid

Hello Experts,
i want to create a screen divided in two parts. The upper side shows general(Header) information and the lower side shows detail information using ALV grid.
When i select a record in the header of the Upper side grid , then the lower side grid will display the corresponding details.
( Initially the first record should be selected and the details for that first record will be displayed . Later user can choose any other record .........)
Could anyone pls tell me the detailed procedure for developing this..i need help.
Thanks & Best Regards
Sudhansu

This example is implemented using docking containers on a selection screen to give you a cut and paste example. Simply copy and past the code into a test program and run it. double click on any line item from the grid at the top. the grid at the bottom will change.
report zrich_0001.
data: imara type table of mara.
data: xmara like line of imara.
data: imarc type table of marc.
data: dockingbottom type ref to cl_gui_docking_container,
 dockingtop type ref to cl_gui_docking_container,
 alv_bottom type ref to cl_gui_alv_grid,
 alv_top type ref to cl_gui_alv_grid,
 repid type syrepid.
* CLASS lcl_event_handler DEFINITION
class lcl_event_handler definition.
public section.
 class-methods handle_double_click
 for event double_click of cl_gui_alv_grid
 importing e_row e_column.
endclass.
* CLASS lcl_event_handler IMPLEMENTATION
class lcl_event_handler implementation.
method handle_double_click.
 read table imara into xmara index e_row-index.
 select * into table imarc from marc
 where matnr = xmara-matnr.
 call method alv_bottom->refresh_table_display( ).
endmethod.
endclass.
parameters: p_check type c.
start-of-selection.
at selection-screen output.
repid = sy-repid.
select * into corresponding fields of table imara
 from mara up to 100 rows.
read table imara into xmara index 1.
check dockingbottom is initial.
create object dockingtop
 exporting repid = repid
 dynnr = sy-dynnr
 side = dockingtop->dock_at_top
 extension = 200.
create object alv_top
 exporting i_parent = dockingtop.
call method alv_top->set_table_for_first_display
 exporting
 i_structure_name = 'MARA'
 changing
 it_outtab = imara[].
* handler for ALV grid
set handler lcl_event_handler=>handle_double_click for alv_top.
create object dockingbottom
 exporting repid = repid
 dynnr = sy-dynnr
 side = dockingbottom->dock_at_bottom
 extension = 200.
create object alv_bottom
 exporting i_parent = dockingbottom.
select * into table imarc from marc
 where matnr = xmara-matnr.
call method alv_bottom->set_table_for_first_display
 exporting
 i_structure_name = 'MARC'
 changing
 it_outtab = imarc[].
The implementation in a dialog program is pretty much the same, you do the logic in the PBO and use custom containers instead of docking containers.
Regards,
RIch Heilman

Dropdown list in tab strip

Hi,
I want a dropdown list for block reason ,in the two tabs that i have created.The dropdown list is not a part of the table contol.
The dropdown list should have the contents of Delivery and Billing block as observed in the 'SALES' tab of VA03.
The functionality of the list is to filter the blocks displayed in the table control according to the reason selected in the list.
Thanks.

Hi
Welcome to SDN Community
LIST BOX
Drop down list box can be created in a dialog screen(SE51) as well as selection screen.
The sap list box allows to select a value from the list but we cannot enter our own value in the list box .The value list that will be displayed consists of two
fields TEXT field of TYPE 80(C) and internal KEY field of TYPE 40(C).
In screen painter to create a input/output field into list box we use
'L" as a value for dropdown attribute for the i/o field.
In screen painter to determine the type of method that will be used to fill the value
list we use the attribute value list.
If it is blank the value list will be filled by the first column of the input help assigned to the screen field.This input help can be defined in the ABAP Dictionary, on screen using SELECT,VALUES screen statements or in event POV (PROCESS ON VALUE-REQUEST ) and the input help that will be passed to the field should consists of 2 columns ,the key column is filled automatically by the system.SAP recommends value list field should be blank.
or
The value can be 'A' meaning that the value list will be filled in the event PBO(PROCESS BEFORE OUTPUT) or before the screen is displayed.In this method we use function module VRM_SET_VALUES to fill the values and pass it to the i/o field.
If a function code is attached to the list box the selection of a value triggers a PAI
otherwise PAI will not trigger.
LIST BOX in SELECTION SCREEN
List Box is created in selection screen using PARAMETERS staement
with AS LISTBOX addition other attributes like VISIBLE LENGTH (width of listbox)
can be specified with the declaration.
PARAMETERS name(n) AS LISTBOX VISIBLE LENGTH n.
Here n is an integer and name is the name of parameter.
To populate the value list we use the FM VRM_SET_VALUES and the
selection screen event AT SELECTION-SCREEN OUTPUT is used to write the code to fill it.
VRM_SET_VALUES
The function module VRM_SET_VALUES is used to fill the value list associated with a List Box .This FM uses types which are declared in type group VRM. So
we should declare TYPE-POOLS VRM before using this FM.
Some important types declared in the VRM type group are
VRM_ID
 It refers to the name of the input/output field associated with list box
VRM_VALUES
It refers to the internal table consisting of two fields TEXT(80C) and KEY(40)C
that will be used to create the list values.
CALL FUNCTION 'VRM_SET_VALUES'
EXPORTING
 ID = name of screen element ,it is of TYPE VRM_ID
 VALUES = internal table containing values,of TYPE VRM_VALUES
LIST BOX with value list from input help
In this example the screen element attribute value list is set to blank as such the value list will be filled with the 1st column of the input help,We use PROCESS ON VALUE-REQUEST event to pass the value list to the listbox.In the MODULE call used to fill the value list we can use FM like F4IF_INT_TABLE_VALUE_REQUEST to create input help as explained in the input help.The value of first column will be shown in the field when selected.
PROCESS ON VALUE-REQUEST
FIELD list MODULE fill_list_100
FIELD list MODULE fill_list_100 INPUT
SELECT f1 f2 FROM table INTO int
CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'
 EXPORTING
 retfield = 'input/output screen field'
 value_org = 'S'
 TABLES
 value_tab = itab "it contains 2 fields that will be shown in the list box
 EXCEPTIONS
 parameter_error = 1
 no_values_found = 2
 OTHERS = 3.
IF sy-subrc <> 0.
ENDIF.
ENDMODULE.
VALUE LIST CREATED IN PBO
In this method we set the value list attribute to 'A'.The value list will be filled in the PBO by using FM VRM_SET_VALUES .
TYPE-POOLS : VRM
DATA : field_id TYPE VRM_ID ,
 values TYPE VRM_VALUES,
 value LIKE LINE OF values.
PROCESS BEFORE OUTPUT
MODULE list_fill_100
MODULE list_fill_100 OUTPUT
SELECT f1 f2 f3 FROM tab WHERE condition.
value-KEY = f1.
value-TEXT = f2
APPEND value TO VALUES
CALL FUNCTION 'VRM_SET_VALUES'
 EXPORTING
 id = 'i/o screen field'
 values = values.
ENDMODULE.
LIST BOX with Selection Screen
For this the FM VRM_SET_VALUES is used to fill the value table and is passed to the parameter created with TYPE LISTBOX in the selection screen event
AT SELECTION-SCREEN.
PROGRAM zlist
TYPE-POOLS : VRM.
DATA: param TYPE vrm_id,
 values TYPE vrm_values,
 value LIKE LINE OF values.
PARAMETERS: p_name(10) AS LISTBOX VISIBLE LENGTH 10.
AT SELECTION-SCREEN OUTPUT.
param = 'P_NAME'.
value-key = '1'.
value-text = 'JOHN'.
APPEND value TO values.
value-key = '2'.
value-text = 'PETER'.
APPEND value TO values.
CALL FUNCTION 'VRM_SET_VALUES'
 EXPORTING id = param
 values = values.
Regards
Pavan

Event on F4 click in classic dialog programming

Hi Experts,
I'd like to ask if there is an event that triggers upon clicking the dropdown in classic dialog or ALV grid. I've been researching for a while and I can't seem to know if it is possible and how it can be done. The scenario is that I should populate a table control with 3 dynamic dropdown fields which are related to each other.
COLUMN1      COLUMN2        COLUMN3
item1-drop1    item1-drop2     item1-drop3
item2-drop1    item2-drop2     item2-drop3
The dropdown list under COLUMN2 depends on what was selected in COLUMN1, and the dropdown list of COLUMN3 depends on what was selected in COLUMN2. The dropdown list should be unique for every record since the value of COLUMN1 will also vary.
I tried to use the FunctionCode but it only triggers after the value has been selected from the dropdown list. This will only suffice if the records are edited 1 at a time, but that is not the requirement. The user should be able to select from the correct drop from any record simultaneously.
If this is not possible with the classic dialog programming, is this doable in ALV grid?
Thanks in advance.
Regards,
Dexter

HI,
Please check the below thread
populate drop down menu based on entry in another field
You need to make minor modifications to adapt it for Table control
Cheerz
Ramchander Roa.K

How to read selected item of the dropdown listbox in dialog prgmming

hello to all,
i need one help.In dialog programming how to read the selected value of the dropdown listbox created in se51. the values are appering in listbox by using FM 'VRM_SET_VALUES' .and function code is also assigned to lisbox .but how to read that one particular value selected by user form the dropdown list.
thanks.

hello mate
Try this following logic and code u will getting the answer
Here this example :
                  Let Name of the LIST BOX BE : LT
Code :
Data Declaration :
I_NATIO TYPE VRM_VALUES,
W_NATIO LIKE LINE OF I_NATIO
data: begin of itab occurs 0,
LT(10) type c,
end of itab.
**This query to data retrival
select x1 x2 into table itab form tbl .
loop at itab.
w_natio-key = itab-LT.
w_natio-text = itab-LT.
append w_natio into i_natio.
clear w_natio.
endloop.
**This code for setting values in the list box
CALL FUNCTION 'VRM_SET_VALUES'
    EXPORTING
      ID     = 'LT'
      VALUES = I_NATIO.
**This code getting the valu form the list box
CALL FUNCTION 'VRM_GET_VALUES'
    EXPORTING
      ID     = 'LT'
    IMPORTING
      VALUES = I_NATIO.
**simply to print the values selected
write : i_natio-lt.
I hope this will help u out.
Anand

Basic Dialog Programming

Hello Everybody and hello World.
I would like to know how to do a basic dialog programming..
Can anyone help me?Please....
give me some advice....Im very eager to learn that dialog programming
Thanks in advance
aVaDuDz

hi
INTRODUCTION TO DIALOG PROGRAMMING
OVERVIEW
There are programs in every domain that require certain amount of user interaction .Such requirements in ABAP are fulfilled with the help of a user dialog and dialog programming which encapsulates the entire logic pertaining to the required user dialog.
One needs to take care that user interactions with the system are comfortable and user friendly along with being logically coherent.

What is a user dialog?
Any kind of user interaction with the system can be called as a user dialog:
1) Entering data on the screen.
2) Clicking a button.
3) Navigation between screens.
Need of dialog programming
In a typical dialog, the system displays a screen on which the user can enter or request information. As a reaction on the user input or request, the program executes the appropriate actions: it branches to the next screen, displays an output, or changes the database.
Example
A travel agent wants to book a flight. The agent enters the corresponding data on the screen. The system either confirms the desired request, that is, the agent can book the flight and the customer travels on the desired day on the reserved seat to the chosen destination, or the system displays the information that the flight is already booked up.
To fulfill such requirements, a dialog program must offer:
A user-friendly user interface
Format and consistency checks for the data entered by the user
Easy correction of input errors
Access to data by storing it in the database.
ABAP/4 offers a variety of tools and language elements to meet the requirements stated above in the dialog programs.
Why dialog programming is also known as module pool?
Dialog Programming consists of screens and corresponding ABAP program. Screens call dialog modules in the associated ABAP program from their flow logic. Type M programs serve principally as containers for these dialog modules, and hence dialog programming is also known as module pools. A module pool program is a program type which is not executable directly. You can not just run by hitting F8 like a report program. You must tie a transaction code to a screen in order to start the program.
VARIOUS COMPONENTS OF A DIALOG PROGRAM
Unlike report, interface or any conversion development which generally entails the creation of one autonomous program which can be executed independently of other objects, dialog program development entails development of multiple objects none of which can be executed on its own. Instead all objects are linked hierarchically to the main program and are executed in a sequence dictated by the Dialog Main Program.
Components of a dialog program
1) Transaction
2) Screen
3) GUI status
4) ABAP program
All these components are explained in detail below.
1) TRANSACTION :
The transaction starts a screen sequence. You create transaction codes in the Repository Browser in the ABAP Workbench or using Transaction SE93. A transaction code is linked to an ABAP program and an initial screen. As well as using a transaction code, you can start a screen sequence from any ABAP program using the CALL SCREEN statement.
2) SCREEN
As a user of an R/3 system, one is always confronted with screens. From the moment one logs on, one can see a screen and one must perform actions on this screen. All those screens are components of ABAP programs. Generally, we define the screens of an ABAP program with the Screen Painter tool of the ABAP.
In the R/3 system, screens are program objects that consist of two parts. First, they have a layout that defines the front end appearance of the window that is presented to the user. Second, they have a flow logic that is executed on the backend by the application server. The screen flow logic is a program layer between the front end and the actual ABAP application program at the backend. The language used to program screen flow logic has a similar syntax to ABAP, but is not part of ABAP itself. Unlike ABAP programs, the screen flow logic contains no explicit data declarations. You define the screen fields by placing elements on the screen mask instead. When you define screen fields by referring to data types in the ABAP Dictionary, the runtime environment automatically creates dialogs for field help, input help, and error handling that depends on the semantics of the data type in the dictionary.
The screen flow logic is similar to an ABAP program in that it contains processing blocks. These processing blocks are event blocks that are triggered by the ABAP runtime environment. The most important event blocks are:
PROCESS BEFORE OUTPUT
The respective event (PBO) is triggered after the PROCESS AFTER INPUT (PAI) processing of the previous screen and before the current screen is displayed.
PROCESS AFTER INPUT
The respective event (PAI) is triggered when the user chooses a function on the current screen.
PROCESS ON HELP REQUEST
This event is triggered when function key F1 is pressed.
PROCESS ON VALUE REQUEST
This event is triggered when function key F4 is pressed.
The main task of these processing blocks is to call ABAP dialog modules using the MODULE statement. During the PBO event, you can call any dialog module in the ABAP program that is marked with the addition OUTPUT. In the PAI event, you can call any dialog module program that is marked with the addition INPUT. The screens of an ABAP program can share the dialog modules of that program. You use the dialog modules called during PBO to prepare the screen and the dialog modules called during PAI to react to the user input.
Each screen of an ABAP program has a unique screen number. The screens of an ABAP program can be combined to form screen sequences. Screen sequences are either built statically by setting the following screen in the Screen Painter or dynamically by overriding the static setting in the ABAP program. The last screen of a screen sequence is always the one where the following screen is set to zero.
HANDLING USER INTERACTIONS
A user can interact in various ways with screens. We distinguish between actions that trigger PAI and those that dont. In general, filling input fields with values does not trigger PAI.
Actions that do trigger PAI include:
Choosing a pushbutton on the screen.
Choosing a specially prepared check box or radio button on the screen.
Choosing a function in the menu, standard toolbar, or application toolbar.
Choosing a function key on the keyboard.
ATTRIBUTES OF SCREEN
Like all objects in the R/3 Repository, screens have attributes that both describe them and determine how they behave at runtime. Important screen attributes for ABAP programming:
 Program
The name of the ABAP program (type 1, M, or F) to which the screen belongs.
 Screen number
A four-digit number, unique within the ABAP program that identifies the screen within the program. If your program contains selection screens, remember that selection screens and Screen Painter screens use the same namespace. For example, if you have a program with a standard selection screen, you may not contain any further screens with the number 1000. Lists, on the other hand, have their own namespace.
 Screen type
A normal screen occupies a whole GUI window. Modal dialog boxes only cover a part of a GUI window. Their interface elements are also arranged differently. Selection screens are generated automatically from the definition in the ABAP program. You may not define them using the Screen Painter. A subscreen is a screen that you can display in a subscreen area on a different screen in the same ABAP program.
 Next screen
Statically-defined screen number, specifying the next screen in the sequence. If you enter zero or leave the field blank, you define the current screen as the last in the chain. If the next screen is the same as the current screen, the screen will keep on calling itself. You can override the statically-defined next screen in the ABAP program.
 Cursor position
Static definition of the screen element on which the cursor is positioned when the screen is displayed. By default, the cursor appears on the first input field. You can overwrite the static cursor position dynamically in your ABAP program by using SET CURSOR FIELD <f>
 Screen group
Four-character ID, placed in the system field SY-DYNGR while the screen is being processed. This allows you to assign several screens to a common screen group. You can use this, for example, to modify all of the screens in the group in a uniform way. Screen groups are stored in table TFAWT.
 Hold data
If the user calls the screen more than once during a terminal session, he or she can retain changed data as default values by choosing System -> User profile -> Hold data.
VARIOUS SCREEN ELEMENTS
A screen can contain a wide variety of elements, either for displaying field contents, or for allowing the user to interact with the program (for example, filling out input fields or choosing pushbutton functions). We use the Screen Painter to arrange elements on the screen.
We can use the following elements:
 Text fields
Display elements, which cannot be changed either by the user or by the ABAP program.
 Input/output fields and templates
Used to display data from the ABAP program or for entering data on the screen. Linked to screen fields.
 Dropdown list boxes
Special input/output fields that allow users to choose one entry from a fixed list of possible entries.
 Checkbox elements
Special input/output fields that the user can either select (value X) or deselect (value SPACE). Checkbox elements can be linked with function codes.
 Radio button elements
Special input/output fields that are combined into groups. Within a radio button group, only a single button can be selected at any one time. When the user selects one button, all of the others are automatically deselected. Radio button elements can be linked with function codes.
 Pushbuttons
Elements on the screen that trigger the PAI event of the screen flow logic when chosen by the user. There is a function code attached to each pushbutton, which is passed to the ABAP program when it is chosen.
 Frame
Pure display elements that group together elements on the screen, such as radio button groups.
 Subscreens
Area on the screen in which you can place another screen.
 Table controls
Tabular input/output fields.
 Tab strip controls
Areas on the screen in which you can switch between various pages.
 Custom Controls
Areas on the screen in which you can display controls. Controls are software components of the presentation server.
 Status icons
Display elements, indicating the status of the application program.
 OK field
Every screen has a twenty-character OK_CODE field (also known as the function code field) that is not displayed directly on the screen. User actions that trigger the PAI event also place the corresponding function code into this field, from where it is passed to the ABAP program. You can also use the command field in the standard toolbar to enter the OK field. To be able to use the OK field, you need to assign a name to it.
All screen elements have a set of attributes, some of which are set automatically, others of which have to be specified in the Screen Painter. They determine things such as the layout of the screen elements on the screen. You can set the attributes of screen elements in the Screen Painter - either for a single element, or using the element list, which lists all of the elements belonging to the current screen. Some of the attributes that you set statically in the Screen Painter can be overwritten dynamically in the ABAP program.
 3) GUI STATUS
Each screen has a GUI status. This controls the menu bars, standard toolbar, and application toolbar, with which the user can choose functions in the application. Like screens, GUI statuses are independent components of an ABAP program. You create them in the ABAP Workbench using the Menu Painter.
4) PROGRAM
Each dynpro refers to exactly one ABAP/4 dialog program. Such a dialog program is also called a module pool, since it consists of interactive modules. Each screen and GUI status in the R/3 System belongs to one ABAP program. The ABAP program contains the dialog modules that are called by the screen flow logic, and also process the user input from the GUI status. ABAP programs that use screens are also known as dialog programs.
In a module pool (type M program); the first processing block to be called is always a dialog module. However, you can also use screens in other ABAP programs, such as executable programs or function modules. The first processing block is then called differently; for example, by the runtime environment or a procedure call. The screen sequence is then started using the CALL SCREEN statement.
DATA TRANSFER BETWEEN SCREEN AND ABAP PROGRAM
During PAI, the system automatically transports all screen fields to identically named global ABAP program fields. At the end of the last PBO module, and before the screen is displayed, all of the data is transported from the ABAP program to any identically named fields in the screen. By standard, all screen data is transported immediately before PAI processing starts. But for the dedicated handling of screen fields for example, to carry out an error dialog you can control the moment at which data is passed from screen fields to their corresponding ABAP fields by using the FIELD statement in the screen flow logic.
regards
navjot
reward points if helpfull

Imp: Module pool Or Dialog programming

Hi ,
I have got a requirement to work on module pool programming.....Please help me with some documents which explains me about it from scratch clearly .
Awaiting for ur reply...........

basics of module pool
OVERVIEW
There are programs in every domain that require certain amount of user interaction .Such requirements in ABAP are fulfilled with the help of a user dialog and dialog programming which encapsulates the entire logic pertaining to the required user dialog.
One needs to take care that user interactions with the system are comfortable and user friendly along with being logically coherent.
What is a user dialog?
Any kind of user interaction with the system can be called as a user dialog:
1) Entering data on the screen.
2) Clicking a button.
3) Navigation between screens.
Need of dialog programming
In a typical dialog, the system displays a screen on which the user can enter or request information. As a reaction on the user input or request, the program executes the appropriate actions: it branches to the next screen, displays an output, or changes the database.
Example
A travel agent wants to book a flight. The agent enters the corresponding data on the screen. The system either confirms the desired request, that is, the agent can book the flight and the customer travels on the desired day on the reserved seat to the chosen destination, or the system displays the information that the flight is already booked up.
To fulfill such requirements, a dialog program must offer:
A user-friendly user interface
Format and consistency checks for the data entered by the user
Easy correction of input errors
Access to data by storing it in the database.
ABAP/4 offers a variety of tools and language elements to meet the requirements stated above in the dialog programs.

Why dialog programming is also known as module pool?
Dialog Programming consists of screens and corresponding ABAP program. Screens call dialog modules in the associated ABAP program from their flow logic. Type M programs serve principally as containers for these dialog modules, and hence dialog programming is also known as module pools. A module pool program is a program type which is not executable directly. You can not just run by hitting F8 like a report program. You must tie a transaction code to a screen in order to start the program.
VARIOUS COMPONENTS OF A DIALOG PROGRAM
Unlike report, interface or any conversion development which generally entails the creation of one autonomous program which can be executed independently of other objects, dialog program development entails development of multiple objects none of which can be executed on its own. Instead all objects are linked hierarchically to the main program and are executed in a sequence dictated by the Dialog Main Program.

Components of a dialog program
1) Transaction
2) Screen
3) GUI status
4) ABAP program
All these components are explained in detail below.
1) TRANSACTION :
The transaction starts a screen sequence. You create transaction codes in the Repository Browser in the ABAP Workbench or using Transaction SE93. A transaction code is linked to an ABAP program and an initial screen. As well as using a transaction code, you can start a screen sequence from any ABAP program using the CALL SCREEN statement.
2) SCREEN
As a user of an R/3 system, one is always confronted with screens. From the moment one logs on, one can see a screen and one must perform actions on this screen. All those screens are components of ABAP programs. Generally, we define the screens of an ABAP program with the Screen Painter tool of the ABAP.
In the R/3 system, screens are program objects that consist of two parts. First, they have a layout that defines the front end appearance of the window that is presented to the user. Second, they have a flow logic that is executed on the backend by the application server. The screen flow logic is a program layer between the front end and the actual ABAP application program at the backend. The language used to program screen flow logic has a similar syntax to ABAP, but is not part of ABAP itself. Unlike ABAP programs, the screen flow logic contains no explicit data declarations. You define the screen fields by placing elements on the screen mask instead. When you define screen fields by referring to data types in the ABAP Dictionary, the runtime environment automatically creates dialogs for field help, input help, and error handling that depends on the semantics of the data type in the dictionary.
The screen flow logic is similar to an ABAP program in that it contains processing blocks. These processing blocks are event blocks that are triggered by the ABAP runtime environment. The most important event blocks are:
PROCESS BEFORE OUTPUT
The respective event (PBO) is triggered after the PROCESS AFTER INPUT (PAI) processing of the previous screen and before the current screen is displayed.
PROCESS AFTER INPUT
The respective event (PAI) is triggered when the user chooses a function on the current screen.
PROCESS ON HELP REQUEST
This event is triggered when function key F1 is pressed.
PROCESS ON VALUE REQUEST
This event is triggered when function key F4 is pressed.
The main task of these processing blocks is to call ABAP dialog modules using the MODULE statement. During the PBO event, you can call any dialog module in the ABAP program that is marked with the addition OUTPUT. In the PAI event, you can call any dialog module program that is marked with the addition INPUT. The screens of an ABAP program can share the dialog modules of that program. You use the dialog modules called during PBO to prepare the screen and the dialog modules called during PAI to react to the user input.
Each screen of an ABAP program has a unique screen number. The screens of an ABAP program can be combined to form screen sequences. Screen sequences are either built statically by setting the following screen in the Screen Painter or dynamically by overriding the static setting in the ABAP program. The last screen of a screen sequence is always the one where the following screen is set to zero.
ATTRIBUTES OF SCREEN
Like all objects in the R/3 Repository, screens have attributes that both describe them and determine how they behave at runtime. Important screen attributes for ABAP programming:
 Program
The name of the ABAP program (type 1, M, or F) to which the screen belongs.
 Screen number
A four-digit number, unique within the ABAP program that identifies the screen within the program. If your program contains selection screens, remember that selection screens and Screen Painter screens use the same namespace. For example, if you have a program with a standard selection screen, you may not contain any further screens with the number 1000. Lists, on the other hand, have their own namespace.
 Screen type
A normal screen occupies a whole GUI window. Modal dialog boxes only cover a part of a GUI window. Their interface elements are also arranged differently. Selection screens are generated automatically from the definition in the ABAP program. You may not define them using the Screen Painter. A subscreen is a screen that you can display in a subscreen area on a different screen in the same ABAP program.
 Next screen
Statically-defined screen number, specifying the next screen in the sequence. If you enter zero or leave the field blank, you define the current screen as the last in the chain. If the next screen is the same as the current screen, the screen will keep on calling itself. You can override the statically-defined next screen in the ABAP program.
 Cursor position
Static definition of the screen element on which the cursor is positioned when the screen is displayed. By default, the cursor appears on the first input field. You can overwrite the static cursor position dynamically in your ABAP program by using SET CURSOR FIELD <f>
 Screen group
Four-character ID, placed in the system field SY-DYNGR while the screen is being processed. This allows you to assign several screens to a common screen group. You can use this, for example, to modify all of the screens in the group in a uniform way. Screen groups are stored in table TFAWT.
 Hold data
If the user calls the screen more than once during a terminal session, he or she can retain changed data as default values by choosing System -> User profile -> Hold data.
VARIOUS SCREEN ELEMENTS
A screen can contain a wide variety of elements, either for displaying field contents, or for allowing the user to interact with the program (for example, filling out input fields or choosing pushbutton functions). We use the Screen Painter to arrange elements on the screen.
We can use the following elements:
 Text fields
Display elements, which cannot be changed either by the user or by the ABAP program.
 Input/output fields and templates
Used to display data from the ABAP program or for entering data on the screen. Linked to screen fields.
 Dropdown list boxes
Special input/output fields that allow users to choose one entry from a fixed list of possible entries.
 Checkbox elements
Special input/output fields that the user can either select (value X) or deselect (value SPACE). Checkbox elements can be linked with function codes.
 Radio button elements
Special input/output fields that are combined into groups. Within a radio button group, only a single button can be selected at any one time. When the user selects one button, all of the others are automatically deselected. Radio button elements can be linked with function codes.
 Pushbuttons
Elements on the screen that trigger the PAI event of the screen flow logic when chosen by the user. There is a function code attached to each pushbutton, which is passed to the ABAP program when it is chosen.
 Frame
Pure display elements that group together elements on the screen, such as radio button groups.
 Subscreens
Area on the screen in which you can place another screen.
 Table controls
Tabular input/output fields.
 Tab strip controls
Areas on the screen in which you can switch between various pages.
 Custom Controls
Areas on the screen in which you can display controls. Controls are software components of the presentation server.
 Status icons
Display elements, indicating the status of the application program.
 OK field
Every screen has a twenty-character OK_CODE field (also known as the function code field) that is not displayed directly on the screen. User actions that trigger the PAI event also place the corresponding function code into this field, from where it is passed to the ABAP program. You can also use the command field in the standard toolbar to enter the OK field. To be able to use the OK field, you need to assign a name to it.
All screen elements have a set of attributes, some of which are set automatically, others of which have to be specified in the Screen Painter. They determine things such as the layout of the screen elements on the screen. You can set the attributes of screen elements in the Screen Painter - either for a single element, or using the element list, which lists all of the elements belonging to the current screen. Some of the attributes that you set statically in the Screen Painter can be overwritten dynamically in the ABAP program.
Regards
navjot
reward points if helpfull

What is difference between report programming and dialog programming?

hi,
what is difference between report programming and dialog programming? plz provide some example code
bye

ABAP programming
Basically reports are used to read database and represent the results in lists.
Reports are collections of processing blocks that the system calls depending on events.
We can use reports to evaluate data from database tables.
Reports are stand alone programs and controlled by events.
A report itself never creates events
steps in report:
Processing the selection screen
Reading the database
Evaluating the data and creating lists
Outputting a list.
1st u write simple logics, after that u can enhance the code as step by step.
http://venus.imp.mx/hilario/Libros/TeachYrslfAbap4/index.htm
http://help.sap.com/saphelp_47x200/helpdata/en/d1/802cfc454211d189710000e8322d00/frameset.htm
http://www.sapdev.co.uk/reporting/reportinghome.htm
Dialog Programming
Structure of a Dialog Program
A dialog program consists of the following basic components:
Screens (dynpros)
Each dialog in an SAP system is controlled by dynpros. A dynpro (DYnamic PROgram) consists of a screen and its flow logic and controls exactly one dialog step. The flow logic determines which processing takes place before displaying the screen (PBO-Process Before Output) and after receiving the entries the user made on the screen (PAI-Process After Input).
The screen layout fixed in the Screen Painter determines the positions of input/output fields, text fields, and graphical elements such as radio buttons and checkboxes. In addition, the Menu Painter allows to store menus, icons, pushbuttons, and function keys in one or more GUI statuses. Dynpros and GUI statuses refer to the ABAP/4 program that control the sequence of the dynpros and GUI statuses at runtime.
ABAP/4 module pool
Each dynpro refers to exactly one ABAP/4 dialog program. Such a dialog program is also called a module pool, since it consists of interactive modules. The flow logic of a dynpro contains calls of modules from the corresponding module pool. Interactive modules called at the PBO event are used to prepare the screen template in accordance to the context, for example by setting field contents or by suppressing fields from the display that are not needed. Interactive modules called at the PAI event are used to check the user input and to trigger appropriate dialog steps, such as the update task.
All dynpros to be called from within one transaction refer to a common module pool. The dynpros of a module pool are numbered. By default, the system stores for each dynpro the dynpro to be displayed next. This dynpro sequence or chain can be linear as well as cyclic. From within a dynpro chain, you can even call another dynpro chain and, after processing it, return to the original chain.
Check this link for basics.
http://sap.mis.cmich.edu/sap-abap/abap09/index.htm
Check this link for Dialog Programming/Table Control
http://www.planetsap.com/Tips_and_Tricks.htm#dialog
Check this SAP Help for Dialog Program doc.
http://help.sap.com/saphelp_nw04/helpdata/en/9f/db9cdc35c111d1829f0000e829fbfe/content.htm
Check this SAP Help link for Subscreens.
http://help.sap.com/saphelp_nw70/helpdata/en/9f/dbabfe35c111d1829f0000e829fbfe/content.htm
Check this link for subscreen demo program.
http://abapcode.blogspot.com/2007/05/demo-program-to-create-subscreen-in.html
Also check this link too.
http://abapcode.blogspot.com/2007/06/dialog-programming-faq.html
http://help.sap.com/saphelp_nw04/helpdata/en/9f/db9cdc35c111d1829f0000e829fbfe/frameset.htm
http://sap.mis.cmich.edu/sap-abap/abap09/sld004.htm
http://help.sap.com/saphelp_nw04/helpdata/en/52/670ba2439b11d1896f0000e8322d00/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/52/670c17439b11d1896f0000e8322d00/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/52/670c17439b11d1896f0000e8322d00/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/9f/db9ccf35c111d1829f0000e829fbfe/frameset.htm
http://abapprogramming.blogspot.com/

Making attributes of field dynamic in dialog program in layout editor.

hi,
to make a field required or possible or hidden, we define its attributes in attributes in layout editor.
is it possible to make attributes of fields that we define in layout editor dynamic ?
if functional people want to make some field non-mandatory or mandatory then they go in configuration, and do it. so does this mean that the attributes of the fields that we define in layout editor during dialog program can be made dynamic.
how is this possible ? because attributes are selected using dropdown, its not a code ?
please help in solving this mystery...

Screen Modifications --
demo_dynpro_modify_simple
demo_dynpro_modify_screen
Please dont forget to reward points
Sudheer

Display month and year in dropdown list on selection screen

Hi
Can anyone tell me how to display months and year in a dropdown list on a selection screen?
also please tell me how to get the first and the last dates upon selecting the month and year on the dropdown list.
Month: January Year:2007 .
After selecting the required month and year, the first date and last date i.e '01.01.2007 - 31.01.2007' should be displayed on the right side.
Reward Points assured..
thanks,
Chetan

Hi..,

Just copy, paste and execute this program !!
type-pools: vrm.
parameters : p_month(2) type n as listbox visible length 10,
p_year(4) type n as listbox visible length 10.
DATA : W_DATE type d, w_ldate type d.
initialization.
perform user_drop_down_list_fordt.
perform user_drop_down_list_foryr.
start-of-selection.
concatenate p_year p_month '01' into w_date.
call function 'BKK_GET_MONTH_LASTDAY'
exporting
i_date = w_date
IMPORTING
E_DATE = w_ldate
write /: w_date,w_ldate.
build user_drop_down_list
form user_drop_down_list_fordt.
data: name type vrm_id,
list type vrm_values,
value like line of list.
data: t_months type t247 occurs 0 with header line.
clear list. refresh list.
name = 'P_MONTH'.
select * into table t_months
from t247 where spras eq 'EN'.
sort t_months ascending by mnr.
loop at t_months.
clear value.
value-key = t_months-mnr.
value-text = t_months-ltx.
append value to list.
endloop.
Set the values
call function 'VRM_SET_VALUES'
exporting
id = name
values = list.
endform.
for year...
form user_drop_down_list_foryr.
data: name type vrm_id,
list type vrm_values,
value like line of list.
clear list. refresh list.
name = 'P_YEAR'.
do 9999 times.
clear value.
value-key = sy-index.
append value to list.
enddo.
Set the values
call function 'VRM_SET_VALUES'
exporting
id = name
values = list.
endform.

Hope this solves ur problem..
regards,
sai ramesh

Dropdown list in dialog programming

Similar Messages

Maybe you are looking for