Subscreen in dialog programming

hi
in my dialog programming i am calling a subscreen .
SELECTION-SCREEN BEGIN OF SCREEN 2000 AS SUBSCREEN.
SELECT-OPTIONS: s_lgort FOR mard-lgort NO INTERVALS.
SELECTION-SCREEN END OF SCREEN 2000.
in PBO
CALL SUBSCREEN SUBSCREEN_2000  INCLUDING SY-REPID '2000'.
now my requirement is i want to control the display of the subscreen.
because my screen look like this, after st location lot of spaces then the input box appears.
plant          _______
sales org    _______
division       _______
st location               _________         ->(multple selection)
now i want to display the subscreen equal space to plant sales org etc.
plant          _______
sales org    _______
division       _______
st location  _______      ->(multple selection)
How to control the display of the subscreen.
Thanks,
Madhu

Hi madhu,
i think no need to control the display in your subscreen.if you placed the fields in the screen directly from database please check the field length of the label st location, noramally this will take the size of corresponding  table field.if you dont want the full size reduce the size of the label in screen painter.
reward if helpful
shibu

Similar Messages

  • 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/

  • Select-Option in Dialog programming

    Hi Experts,
      Can we use select-options in Dialog programming?
    If yes, Please help me, how to do that?
    <REMOVED BY MODERATOR>
    Edited by: Alvaro Tejada Galindo on Jun 12, 2008 12:27 PM

    Hi Asrar,
    Definitely you can use select-options in dialog programming.
    You can do this using Subscreen.
    define this scubscreen in top include.
    selection-screen : begin of screen 100 as subscreen.
    select-option : kunnr for kna1-kunnr.
    selection-screen : end of screen 100.
    in screen 200 where this selection screen appears, create a subscreen area 'SSA'.
    Process on output. "200 screen.
    call subscreen SSA including sy-repid '100'.
    other modules
    Process on input.    "200 screen.
    call subscreen SSA.
    other modules
    now you can access kunnr like other screen 200 objects.
    <REMOVED BY MODERATOR>
    Regards
    Megha
    Edited by: Alvaro Tejada Galindo on Jun 12, 2008 12:27 PM

  • Select-Options in dialog program

    Hi there,
    I'm using a selection-screen in a dialog program, I declared it in the TOP.
    Selection-screens
    SELECTION-SCREEN BEGIN OF SCREEN 101 AS SUBSCREEN.
    parameters: p_lifnr type lfa1-lifnr  obligatory ,
                p_werks type t001w-werks obligatory .
    SELECT-OPTIONS:
      s_licha FOR zbrtconsig-licha.
    SELECTION-SCREEN END OF SCREEN 101.
    I have to use the event at selection-screen on value-request for s_licha-low, and I need the values from the fields p_lifnr and p_werks. the problem is:
    If I only fill the fields p_lifnr, p_werks and click on F4 for s_licha, the values of p_lifnr and p_werks are not updated, they are empty. Only wether I do an Enter this fields is updated.
    Thanks,
    Alexandre Nogueira

    Hi,
    i am not clear about your problem, please expalin it clearly.
    use FM : DYNP_VALUES_UPDATE to update screen fields.
    use FM : DYNP_VALUES_READ to read screen fields.
    use SET /GET Parameter id's to set parameters
    this FM will update the screen fields before to PBO event.
    check this link for sample code :
    Re: Issue Related to Module pool
    Regards
    Appana

  • Select-option field in dialog programming

    hi guys,
    i need to declare field matnr as select-option range in dialog programming..how can i code it in the module program?

    This questions has been answered many times (even in february)
    - search sdn wiki (2 commented samples at [SELECT-OPTIONS on Dialog programming screen|http://wiki.sdn.sap.com/wiki/display/ABAP/SELECT-OPTIONSonDialogprogrammingscreen] and [Select-Options in Module Pool Programming|http://wiki.sdn.sap.com/wiki/display/ABAP/Select-OptionsinModulePoolProgramming])
    - search abap online help ([SELECTION-SCREEN - AS SUBSCREEN |http://help.sap.com/abapdocu_70/en/ABAPSELECTION-SCREEN_SUBSCREEN.htm] with sample at [Selection Screens as Subscreens |http://help.sap.com/abapdocu_70/en/ABENSEL_SCREEN_SUBSCREEN_ABEXA.htm])
    Regards,
    Raymond

  • How to use custom control in Dialog Programming?

    How can I call a subscreen using custom control in Dialog Programming?
    The required subscreen contains a calender. Any class or something available for this purpose. Please suggest.

    As [vinraaj|http://forums.sdn.sap.com/profile.jspa?userID=3968041] wrote, call transaction SE51, there is a Wizard to help you generate the table control, it will create the table control and some includes with PBO/PAI modules > Read [Using the Table Control Wizard|http://help.sap.com/saphelp_bw/helpdata/en/6d/150d67da1011d3963800a0c94260a5/frameset.htm]
    Also there is a tutorial in the wiki, read [Learn Making First Table Control |http://wiki.sdn.sap.com/wiki/display/ABAP/LearnMakingFirstTableControl] by [Krishna Chauhan|http://wiki.sdn.sap.com/wiki/display/~nc0euof]
    Regards,
    Raymond

  • Selction screen in dialog program

    Hi All..
    In my requirement, i need a selection screen that has a parameter for the PO number. Based on the valid PO number, the line items of the PO need to be displayed on the screen where the user should be able to split the line items into different batches.
    Once batch split is done, need to do a GR for the updated split data. Appreciate your help on how this can be acieved. Can we design a selection screen in dialog program ?
    Also how we can provide the split functionality (insertion of new rows for main line items to have the user enter new rows for exisitng line items to enter new batch number and quantity).
    Thanks and appreciate your help.

    <i>Can we design a selection screen in dialog program ?</i>
    Yes, you can be defining the selection screen as a subscreen and then embeding in a subscreen area of a dynpro, but it is  hardly worth it for just a parameter, it would be a different story if it were a select-option.  
    You can simply add the parameter to the dynpro using a regular input field.
    Regards,
    Rich HEilman

  • Implement F4 Value-Request Functionality in Dialog Programming

    Hi. Apologies in advance if this is the wrong forum.
    I'm on R/3 4.6c.
    What is the best way to implement this:
    AT SELECTION-SCREEN ON VALUE-REQUEST FOR xxxx-low.
    in a dialog program?
    I have my selection screen defined in my TOP include, but since dialog programs don't support report events I am not sure what to do.
    Thank you for any assistance you could provide.
    Best Regards,
    Brett

    make a new include like
    include progname_screen_1001. at the top of your program.
    goto include.
    write the code below in your include.
    SELECTION-SCREEN BEGIN OF SCREEN 1001.
    write here your selection options and parameters.
    also but here the code you want:
    AT SELECTION-SCREEN ON VALUE-REQUEST FOR xxxx-low.
    SELECTION-SCREEN END OF SCREEN 1001.
    call the screen from anywhere:
    call screen 1001.
    if you want the selection-screen as subscreen than write
    SELECTION-SCREEN BEGIN OF SCREEN 1001 as subscreen .
    write here your selection options and parameters.
    also but here the code you want:
    AT SELECTION-SCREEN ON VALUE-REQUEST FOR xxxx-low.
    SELECTION-SCREEN END OF SCREEN 1001.
    when calling it
    write it to PBO of your screen in which you but an subscreen area named subsel.
    CALL SUBSCREEN SUBSEL INCLUDING 'PROGRAMNAME' '1001'.

  • Dialog programming - How to place a select-option field in a dialog screen

    Hi all,
    In Dialog Programming, How to place a select-option field in a dialog screen.
    Kindly give me some example code...
    Thanks,
    Jaffer Ali.S

    hi Ali,
    U can add select-options in ur module pool by using  SELECTION-SCREEN BEGIN OF SCREEN <scrn> AS SUBSCREEN  command.
    check this link for reference.....
    http://help.sap.com/saphelp_47x200/helpdata/en/e7/deb237b9a9a968e10000009b38f8cf/frameset.htm
    Example Code :
    DATA : ok_code TYPE sy-ucomm.
    SELECTION-SCREEN BEGIN OF SCREEN 1010 AS SUBSCREEN.
    SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE text-001.
    PARAMETERS: p_rad1 RADIOBUTTON GROUP grp1 DEFAULT 'X',
                p_rad2 RADIOBUTTON GROUP grp1,
                p_rad3 RADIOBUTTON GROUP grp1.
    SELECT-OPTIONS: s_matnr FOR  mara-matnr,
                    s_matkl FOR  mara-matkl,
                    s_mtart FOR  mara-mtart.
    SELECTION-SCREEN END OF BLOCK b1.
    SELECTION-SCREEN END OF SCREEN 1010.
    START-OF-SELECTION.
      CALL SCREEN 100.
    *&      Module  STATUS_0100  OUTPUT
    MODULE status_0100 OUTPUT.
    SET PF-STATUS 'xxxxxxxx'.
    SET TITLEBAR 'xxx'.
    CALL SCREEN 1010 .
    ENDMODULE.                    "status_0100 OUTPUT
    *&      Module  USER_COMMAND_0100  INPUT
          text
    MODULE user_command_0100 INPUT.
      CASE ok_code.
        WHEN 'EXIT'.
          LEAVE PROGRAM.
      ENDCASE.
    ENDMODULE.                 " USER_COMMAND_0100  INPUT
    SCREEN 100 ****************
    PROCESS BEFORE OUTPUT.
      MODULE status_0100.
      CALL SUBSCREEN sub_1010 INCLUDING sy-repid '1010'.
    <b>***** where sub_1010 is name of sub-screen area</b>
    PROCESS AFTER INPUT.
      CALL SUBSCREEN sub_1010.
      MODULE user_command_0100.
    <<< REMOVED BY MODERATOR >>>
    Harimanjesh AN
    Edited by: Marcelo Ramos on Dec 17, 2008 7:54 PM

  • Dialog program and report

    I have to create a dialog screen with a bunch of input fields that should be used by user to specify a search range . I know in reports it can be done with select options. How can it be done in dialog program. Also can I create a report and on executing the report can I call a dialog porgram screen
    Thank you

    You can embed a selection screen definition directly into your dynpro via a subscreen. Here is an example.
    report zrich_0006 .
    tables: mara.
    * Custom Selection Screen 1010
    selection-screen begin of screen 1010 as subscreen.
    selection-screen begin of block b1 with frame title text-001.
    parameters: p_rad1 radiobutton group grp1 default 'X',
                p_rad2 radiobutton group grp1,
                p_rad3 radiobutton group grp1.
    select-options: s_matnr for  mara-matnr,
                    s_matkl for  mara-matkl,
                    s_mtart for  mara-mtart.
    selection-screen end of block b1.
    selection-screen end of screen 1010.
    start-of-selection.
      call screen 100.
    *&      Module  STATUS_0100  OUTPUT
    module status_0100 output.
    *  SET PF-STATUS 'xxxxxxxx'.
    *  SET TITLEBAR 'xxx'.
    endmodule.
    *&      Module  USER_COMMAND_0100  INPUT
    module user_command_0100 input.
    endmodule.
    * Screen screen 100 with a subscreen area called "subscreen_1010"
    * Screen Flow Logic follows
    *process before output.
    *  module status_0100.
    *  call subscreen subscreen_1010 including sy-repid '1010'.
    *process after input.
    *  call subscreen subscreen_1010 .
    *  module user_command_0100.
    Regards.
    Rich  Heilman

  • 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.

  • Material on dialog programming

    Hi al,
    does anybody have good material on dialog programming.
    SPECIALLY ON TABLE CONTROL
    THANKS

    Hi
    Go thru this docu
                        TRANSACTIONS
    TABLE OF CONTENTS
    TABLE OF CONTENTS     2
    GENERAL INTRODUCTION TO TRANSACTION     5
    Logical Unit of Work (LUW)     5
    DYNPRO concept     6
    SCREEN PAINTER     7
    Using Screen Painter     7
    Creating a new Screen     7
    Designing of Screen     8
    Selecting Screen Fields     9
    Attributes of Screen Elements     9
    Field List     10
    Screen Flow Logic     10
    MODULE POOL PROGRAMMING     12
    Creation of Module Pool Program     12
    Communication between Dynpro and Module Program     12
    CREATION OF A COMPLETE TRANSACTION     12
    Steps involved to create a complete transaction     12
    Handling Function Code     13
    THE FIELD CHECKS     14
    Automatic Field Checks     14
    About at Exit – Command     15
    In module pool program.     15
    Flow Logic Validations     16
    Module  assign.     16
    Module Pool Program Validations     17
    DYNAMICALLY CALLING THE SCREENS     19
    About Displaying Next Screen     19
    Set Screen     20
    Call Screen     20
    Leave to screen     21
    SUBSCREENS     22
    TABLE CONTROLS     23
    Features of Table Controls     23
    Declaring of Table Control in the Module Pool Program     24
    Designing Table Control on Screen     24
    Passing data to Table Control     24
    STEP LOOPS     27
    Types of Step Loops     27
    Switching To List Mode     28
    Returning back from LIST mode     28
    Process on HELP-REQUEST event     29
    Value Request     30
    THE SCREEN DISPLAYED IS POP-UP SCREEN AND CODE FOR THE FLOW LOGIC AND MODULE IS WRITTEN BELOW:     32
    Need To Change Screen     34
    Modifying the screen     34
    Field Name       Length  Description     34
    MODULE MODIFY_SCREEN.     35
    LOOP AT SCREEN.     35
    ENDMODULE.WORKING WITH MATCHCODE OBJECTS     35
    WORKING WITH MATCHCODE OBJECTS     36
    Creating Matchcode object     36
    Creating Matchcode ids.     37
    Using Matchcode     38
    Creating Lock Objects     39
    Activation of Lock Object     40
                                                                                    GENERAL INTRODUCTION TO TRANSACTION
    Transaction, in R/3 system is an operation that lets the user make necessary changes to the database. The entire R/3 system is nothing but set of business transaction. The data transfer from old system to SAP R/3 database, or modifying data, or deleting data, which is not required, is done through transaction.
    For SAP system, Transaction is nothing but sequence of steps called as dialog steps and for user it is sequence of screens that appears one after the other depending upon the option he selects. The special transaction monitor called the SAP dispatcher handles the sequence of steps that takes place in any transaction. The main task of transaction is to update database table. The database table is not updated until a transaction is completed. All changes can be rolled back if the transaction has not finished.
    The transaction contains two steps which are as following:
    •     Interactive phase: In this step, user enters the data, which needs to be inserted or deleted or modified on to the screen. There can be single screen or multiple screens depending upon the transaction. So this step can consist of single step or multiple steps.  In this phase you prepare database record.
    •     Update phase: This phase processes the database record and updates the database table. Actual updating of database table takes place in this phase.
    All the transactions are associated with transaction code. And all these codes are stored in a table TSTC.
    Logical Unit of Work (LUW)
    The R/3 system is multi user system and many users access the same information at the same time, which is mainly DATA. Consider the case where one user is modifying a record, and second user is trying to delete the same record. If the second user is successful in deleting the record then the first user will face problem for modifying the record that is already deleted. The avoid such situation, R/3 system has provided Logical Unit of Work, which is defined as a locking mechanism to protect transaction integrity. Of course, there are other measures, which ensures data integrity like check table i.e. foreign key relationship. Within SAP system there are three types of transaction and may be distinguished as:
    •     Database transaction known as LUW.  It can be defined as a period in which operation requested must be performed as a unit, i.e. all or nothing operation.  At the end of LUW, either of the database changes are committed or rolled back.
    •     Update transaction or SAP LUW.  One SAP LUW can have several databases LUW. So a set of a database is either committed or rolled back. The special ABAP/4 command COMMIT WORK, marks the end of a SAP LUW.
    •     ABAP/4 transaction. Is made up of a set of related task combined under one transaction code. ABAP/4 transactions are for programming environment, in which ABAP/4 transaction functions like one complete object containing screens, menus and transaction codes.
    R/3 system has provided in built locking mechanism, which defines the Logical Unit of Work. Also user can set his own locking mechanism. The LUW starts when a lock entry in the system table is created, and it ends when the lock is released.
    To provide the user the facility to communicate with the table in order to modify or delete or insert data, R/3 has provided tool called SCREEN PAINTER. This tool allows you to design screen, process screen through program and update the database table.  SAP has provided one and only one way to update the database table, i.e. transaction.  Though you can update database table by using open SQL statement through program, SAP usually doesn’t recommend this kind of updating.  Many standard transactions are available to update standard table but if the need arises, the developer should be able to develop new transaction, which allows the updating of database tables. This can be achieved by using various components of screen painter.
    Following are the few concepts and steps for creating entire new transaction.
    DYNPRO concept
    A dynpro refers to the screen + flow logic. With screen painter you can develop screen and flow logic. The relationship between screen, flow logic, and program can be shown as follows:
    Dynpro, as figure indicates consist of screen and flow logic and places exactly one call to module pool program. A transaction consists of many screens and for each screen flow logic is attached. When the transaction is executed, the screen places a call to flow logic and flow logic in turn places a call to module pool program.
    •     A module program is usual ABAP/4 program that consist of modules and data declaration.
    •     ABAP/4 is an event driven language. In module pool program too, events get triggered and these events are handled in flow logic. Flow logic editor is subset of ABAP/4 editor. The system automatically displays the two important events for the flow logic.
    •     Screen is the important component of dynpro and can be created, designed by screen painter.
    Screen Painter
    A screen painter can be started by
    Development workbench &#61664; Screen Painter
    Or
    SE51 transaction code.
    Using Screen Painter
    The process of creating a dynpro includes the creation and definition of all the needed screen components.
    The steps involved in creating the dynpro are as follows:
    •     Create screen and attributes by using screen attribute screen.
    •     Select and place the needed fields within the screen by using dict/program fields.
    •     Establish the field attributes to which the screen belongs by using field list.
    •     Define the flow logic respect to the transaction to which it belongs by using flow logic.
    Creating a new Screen
    Steps involved are as follows:
    •     Enter the name of program and number of the screen
    •     Click on Create
    •     On “screen attribute” screen enter short description
    •     Enter screen type. Normally, you select NORMAL option for usual R/3 screen. Other options available are SUBSCREEN & MODAL DIALOG BOX. Modal dialog box is used to establish independent and interactive dialog box while subscreen is screen within screen. 
    •     Next attribute to be passed is NEXT SCREEN. Here you need to specify the next screen number, which must be processed after the current one.
    Designing of Screen
    Screen can be designed by using FULL SCREEN EDITOR. You can go to full screen editor.
    From screen attribute screen
    By pressing full screen editor pushbutton
    Or
    From initial screen of screen painter.
    There are two modes available with full screen editor.
    •     Graphical mode. The graphical mode works similarly to typical window application.
    •     Alphanumeric mode (rarely used).
    Elements of screen
    •     Text – Standard text or field labels.
    •     Entry  - display field.
    •     Radiobutton – All radiobutton must be associated with one group.
    •     Checkbox – Normally used for YES/NO operations.
    •     Pushbutton – Used for activating particular function.
    •     Boxes – grouping together many screen elements.
    •     Subscreens – This is a screen area in which you can display another screen.
    •     Table controls – This area of screen is similar to table but should be treated as a loop.
    •     Status - Display output fields containing icon.
    All these elements are on the control bar of full screen editor and can be placed on the screen work area by clicking and placing them wherever needed.
    Selecting Screen Fields
    Screen field can be either dictionary objects or program fields. Steps involved in the placing of fields on the screen are as follows:
    Click the pushbutton Dict/program fields on the full screen editor
    Or
    Goto &#61664; dict/prog fields.
    •     Enter table name.
    •     Click Get from dictionary.
    •     Select fields.
    •     Click copy pushbutton.
    •     Position the cursor where you want those fields to be placed.
    To adjust various screen elements, you can use drag and drop facility for screen elements.
    Attributes of Screen Elements
    The entire element of a screen has some attributes, which determines their behavior.
    •     General – These attributes are directly managed by the screen painter like name of the element, or text of element or column width and various things associated with the screen.
    •     Dictionary – These attributes are applicable to fields, which are from dictionary. Various components of dictionary can be attached to this element like search help, foreign key.
    •     Program.
    •     Display – Behavior of the element with respect to their display feature.
    Attribute dialog box can be displayed by
    •     Clicking on the ATTRIBUTE push button on the application tool bar.
    •     Double clicking on the element.
    Field List
    This list displays a list of all screen elements together with their screen attributes.  One important element of Field list is OKCODE. Any pushbutton is associated with function code as in menu item in menu painter. When the user clicks the pushbutton this code is stored in OKCODE. This OKCODE is created by system without a name and is not visible on the screen. In ABAP/4 this field is work field and is nothing but an area wherein system stores the variable and is the last field of the field list and is invisible, hence user needs to give the name OKCODE. It is not mandatory to give the name OKCODE; developer can give any name to this field.
    Screen Flow Logic
    You can go to this screen either by
    Initial screen of Screen painter &#61664; Flow logic
    Or
    From Screen attribute screen &#61664; Flow logic
    When transaction is executed, the screen is displayed, user enters few fields, selects few functions. Later the screen is processed and processing of screen is done by flow logic.    The events that are associated with screen are as follows:
    •     Process before Output (PBO)
    •     Process after input (PAI)
    •     Process on value request (POV)
    •     Process on help request (POH)
    The system automatically displays two very important events or modules in flow logic i.e. PAI and PBO
    PBO event
    This event is triggered before the screen is displayed. The processing of screen before the display of screen is done in this event. For example, filling in default values in the screen fields. 
    PAI event
    This event is responsible for processing of screen after the user enters the data and clicks the pushbutton. The processing of screen can include displaying another screen, or just displaying list or quitting the transaction itself and many more things. Usually it is displaying another screen. These operations can be carried out in the PAI event. OKCODE plays an important role in this operation.
    POV event
    Process on value request is triggered when the user clicks F4 key. You can handle this event when the user presses F4 key by writing code for the same in module pool program. Normally when the user presses F4, list of possible values is displayed.  The standard list produced by system is adequate for applications you develop yourself.  However, you can also have the option of setting up your own documentation and lists of possible values that are more detailed.
    POH event
    Normally when the user places the cursor on the field and presses F1 function key, the system displays its own Help for that particular field. You can add your own functionality to the Help button by writing code for the same in the POH event.
    Module Pool Programming
    This component though is not attached to the screen painter, plays important role in transaction. Normally, for reports, on line executable programs are written but for transaction, Module Pool Programs are written. The module pool program contains only modules to handle various events associated with screen and data declaration statements.
    System divides the module pool program into several include program. These are global field, PBO modules, and PAI modules. It is entirely user’s decision whether to use these modules or write directly into main program.
    Creation of Module Pool Program
    You can create module pool program either through
    Object browser
    System automatically creates the module pool program and for these program which are created through object browser, system creates the include modules.
    Or
    ABAP/4 editor
    It is similar to normal program creation. Type of program should be given ‘M’ and is not created by system.
    Communication between Dynpro and Module Program
    For each screen, the system executes the flow logic, which contains corresponding events. The control is passed to Module Pool Program. Module Pool Program handles the code for these events and again passes back control to the flow logic and finally to screen. Unlike on line program, in this case, the control remains with flow logic. The switching of control between flow logic and module pool program and back is common process when user executes transaction.
    Creation of a Complete Transaction
    Steps involved to create a complete transaction
    •     Create module pool program.
    •     From screen painter create screens.
    •     Write flow logic for each screen.
    •     Write code for all the events in module pool program.
    •     Check for any error in screen and flow logic.
    •     Generate each and every component of screen i.e. flow logic and screen.
    •     Single screen can be tested using Screen Painter.
    •     Create transaction code through object browser.
    •     Generate the transaction code.
    •     User can execute the transaction by entering the transaction code in the command field.
    Handling Function Code
    The function code or OKCODE is the last field of Field list. Function code can be handled as follows:
    During the Designing of the screen, a function code is assigned to pushbutton.
    •     In field list, developer needs to specify OKCODE as last field.
    •     In module program it is a global field and can be evaluated in the PAI event.
    •     A function code is treated in the same way, regardless it comes from pushbutton, menu item or any other GUI element.
    A complete example for transaction is shown below:
    If you have a screen like the one below:
    When the user clicks on the Display button, you want to display details of sflight, with corresponding carrid and connid (which is entered by the user).
    Module pool program to handle this particular screen is as follows:
    Program YVTEST7.
    TABLES: SFLIGHT.
    DATA: OKCODE (4).
    MODULE INPUT1 INPUT,
    CASE OKCODE.
       WHEN ‘DISP’.
         SELECT * FROM SFLIGHT
                WHERE CARRID =  SFLIGHT – CARRID AND
                               CONNID = SFLIGHT – CONNID.
         ENDSELECT.
         LEAVE TO SCREEN 200.
       WHEN ‘EXIT’.  LEAVE TO SCREEN 0.
      ENDCASE.
    ENDMODULE.               “INPUT1 INPUT
    MODULE USER_COMMAND_0200 INPUT.
    CASE OKCODE.
    WHEN ‘BACK’. LEAVE TO SCREEN 100.
    ENDCASE.
    ENDMODULE.                    “USER_COMMAND_0200 INPUT
    When the user clicks on display, control is transferred to screen no. 200 on which you display sflight details & on the same screen, when user clicks on BACK button, he comes back to main screen.
    Flow logic for screen 100 is as follows:
    PROCESS AFTER INPUT.
    MODULE INPUT.
    Flow logic for screen 200
    PROCESS AFTER INPUT.
    USER_COMMAND_0200.
    MODULES: Modules are handled in module pool program.
    You need to write flow logic for screen 200 and design screen 200.
    In case of transaction transfer of data from program to screen is automatic i.e. you need not transfer the data from program to screen explicitly. The fields, which you define in the screen receives the data from program and displays the same.
    The Field Checks
    As already mentioned Transaction is the only method, which SAP recommends to update the database tables. Data entered in the database table should be valid and correct. Data entered is validated at each and every point. ABAP/4 offers various methods to validate data and those are as follows:
    •     Automatic field checks
    •     Checks performed in the flow logic
    •     Checks performed in the ABAP/4 module pool program
    Automatic Field Checks
    These checks are based on the field information stored in the dictionary. These checks are performed by the system automatically when the user enters the data for the screen field. System performs these checks before PAI event is triggered. Types of field checks performed by system are as follows:
    •     Required input
    While designing the screen, for particular screen field if you click the Req. Entry checkbox, the field becomes mandatory. When the transaction is executed if user leaves this particular field blank, the system displays error message. User cannot proceed until the user enters some data.
    •     Proper Data Format
    Each field has its own data format whether it is table field or screen field. Whenever data is entered, system checks for the proper format of the data. For example date. Each user has its own format for date, which is defined in the user master record. If the date defined in the user master record is in the format DD/MM/YYYY, if the user enters the date, say, in YY/DD/MM, the user displays the error message. System also checks for the value of month or days. For example if month entered is greater than twelve then the error message is displayed.
    •     Valid Value for the Field
    In data dictionary two tables are related by Primary key-Foreign key relationship.  Whenever the user enters the data, the system checks for the check table values.   Also in Domain, if you have fixed values, then the system checks for these values.
    Automatic field checks are repeated each time the user enters the data.
    About at Exit – Command
    Automatic field checks can be avoided by AT EXIT-COMMAND, which works exactly the same way as Cancel works on application tools bar. In the R/3 screen, if you want to quit the processing of that particular screen without entering the mandatory fields, user can click the Cancel button. Same functionality can be incorporated in the user-defined transaction by using AT EXIT-COMMAND. This module can be called before the system executes the automatic field checks and it goes without saying that before PAI event. Code for AT EXIT-COMMAND in flow logic and in module pool program can be written as follows:
    In Flow Logic
    Process After Input.
    Module exit AT EXIT-COMMAND.
             In module pool program.
    Module exit.
    Case okcode.
    When ‘Exit’.
    Leave to screen 0.
    To achieve this kind of functionality a pushbutton or menu item should be assigned a function type ‘E’. It tells the system to process this particular module before carrying out any field checks.
    Flow Logic Validations
    Consider the case where you want user to enter only ‘LH’ and ‘SQ’ for sflight-carrid. In this case, you are restricting value of a screen field. This cannot be achieved by automatic field check. Hence there is a need of additional validation. It can be done in flow logic by using following statement:
    Field -
    Values
    Syntax
    PAI.
    Field sflight-carrid values (‘LH’).
    For multiple values
    PAI.
    Field sflight-carrid values (‘LH’ ‘SQ’).
    Field sflight-price values (between 1000 and 2000).
    In this case when the user enters the value, PAI is triggered  and field is checked for  that particular value. If the value entered happens to be wrong, that field is enabled for user to enter. If you have multiple Field statements in your flow logic, it is sequential execution.
    Consider the following case:
    PAI.
    Module  assign.
    Field sflight-carrid values (‘LH’ ‘SQ’).
    In ABAP/4
    Module  assign.
    Data: carrid1 like sflight-carrid.
    Carrid1 = sflight-carrid.
    Endmodule.
    In this case, Sflight-carrid is used in the flow logic before the field statement. The system will give invalid value or some previous value as the field sflight-carrid is used in module before it is checked i.e., field statement is after the module in which sflight-carrid is being used. The field is not available to the system unless it executes the field statement. Field statement transfers the values to the program and is done only once. If you don’t have Field statement in your flow logic, transfer of values takes place in PAI event.
    Consider one more case where you have multiple field statement.
    PAI.
    Field Sflight-carrid values (‘LH’).
    Field Sflight-connid values (‘0400’ ‘0500’).
    In this case if the user enters only carrid wrong, then this particular field is enabled and rest of the fields are disabled for user to input. Many times if the user enters wrong value for one field, then you might want to give option to user to enter all the fields, which is not possible by using Field statement only. This functionality can be achieved by CHAIN – ENDCHAIN.
    Syntax
    Chain.
    Field sflight-carrid value (‘LH’).
         Field sflight-connid values (between ‘200’ and ‘500’).
    Endchain.
    Field sflight-price values (‘100’ ‘1000’).
    In this case, if the user enters wrong value only for carrid, both the fields i.e. carrid and connid are enabled as they are grouped together in the Chain statement. The field price will be disabled for input. Usually, logically related fields are grouped together with Chain-Endchain statement.
    Module Pool Program Validations
    Checking fields ABAP/4 program includes
    •     Field statement in flow logic.
    •     Module statement in ABAP/4 module pool Program.
    Syntax
    PAI.
    Field sflight-carrid module <name>.
    This module can be handled in the main program i.e. module pool program.
    In ABAP/4 program
    Module Check.
    Select single * from sflight where carrid = sflight-carrid.
    If sy-subrc ne 0.
         Message e001.
    Endif.
    In this case, field sflight-carrid is checked in the table for its existence.
    Dynamically Calling the Screens
    About Displaying Next Screen
    Transaction is a sequence of screens, which are displayed one after the other. The next screen displayed depends upon the attributes of first screen. In attributes you need to give Next Screen number i.e. if next screen displayed should be 200 screen, then this number should be given in next Screen attributes. These are static attributes of the screen. By default, if nothing is specified in the program, the system branches out to the screen number, which is specified in the attribute screen.
    But this doesn’t happen always. If you have many pushbuttons on the screen like the one in the following case:
    In this case, if user selects MARA pushbutton, then fields from Mara table are displayed. When the user clicks on the MARD, then the fields from MARD table are displayed. Depending upon users selection, the screen is branched out and this has to be done during runtime. This functionality can be achieved by dynamically calling the screen in module pool program.
    The screen can branch out to new screen depending upon user selection. Following command in module pool program can do this:
    •     SET SCREEM
    •     CALL SCREEN
    •     LEAVE TO SCREEN <NUMBER>
    All these commands override the specifications given in the attributes. This overriding is temporary. The values stored in the attribute are not changed.
    Set Screen
    Syntax
    Set screen <number>.
    In module pool program
    Case okcode.
         When  ‘DISP’.
              Set screen 200.
         When ‘LIST’.
              Set screen 300.
    Endcase.
    In this case, the entire processing of current screen takes place and then the system branches out to next screen. If you want to branch out to the next screen without processing the current screen, LEAVE SCREEN should be used along with the SET SCREEN.
    For Example:
    Case okcode..
         When  ‘DISP’.
              Set screen 200.
              Leave Screen.
         When ‘LIST’.
              Set screen 300.
              Leave Screen.
    Endcase.
    When SET SCREEN is used, control cannot be transferred to the main screen or previous screen, unless you write code for the same.
    Call Screen
    Usually used for pop up screens. Many times, there is a need for user to enter additional information or secondary information on another screen or pop up screen. Once the user enters the data, he should be able to go back to main screen or to the screen where he started. This is not possible by using SET SCREEN. CALL SCREEN achieves this functionality.
    Syntax
    Call Screen 200.
    Will simply call a screen number 200 from a main screen. Once the screen is displayed the user can enter all the data and return to the main screen by clicking BACK button.
    To call screen as pop up screen the syntax is
    Call screen starting at <col.no.> <line no>
                         Ending at <col no> <line no>.
    In this case window will be popped as window and user can close it by using BACK button.
    Leave to screen
    To SET a new screen without processing current screen, you need to use the following two statements together:
    SET SCREEN 200.
    LEAVE SCREEN.
    Or a Single statement
    LEAVE TO SCREEN 200.
    Subscreens
    A subscreen is a screen within screen. Consider the following case.
    If user clicks on FIRST pushbutton, you want to display details of MARA table and if user clicks on the SECOND pushbutton, you want to display details of MARD table.  You can do this by calling two different screens. But the information will be displayed on the next screen. Displaying data on the same screen is possible by using SUBSCREENS.
    Step to create a subscreen are as follows:
    •     Create a subscreen area on MAIN screen and name it.
    •     Create a separate screen of subscreen type.
    •     Arrange the fields on this screen so that they fit in subscreen area exactly. Only when it is larger, the part of the screen that fits in the main area will be visible.
    •     Write code for calling subscreen in flow logic.
    To call subscreen, from your flow logic, you need to include the statement both in PAI and PBO.
    Syntax
    PBO.
    Call subscreen <area> including <prg name> <’screen no’>.
    PAI.
    Call subscreen <area>.
    Area - is the name of the area on main screen.
    Prg. Name - is the name of the module pool program.
    Screen number - is subscreen screen number.
    Some of the don’ts with subscreen are:
    GUI status cannot be set to the subscreen
    •     OKCODE is not applicable to the subscreen.
    •     Subscreen cannot call another screen.
    •     It cannot contain AT EXIT-COMMAND.
    You can call multiple subscreen in the same area (at any given point of time, only one subscreen can be called in the subscreen area) and is done dynamically during runtime by using variable screen number.
    Table Controls
    A table can be created in transaction. These tables when designed on the screen are called as SCREEN TABLES. These screen tables are of two types viz.
    •     Table controls
    •     Step loops
    Though these are tables when code is written to handle them, the  tables are treated  as loops. 
    Features of Table Controls
    •     Data is displayed in the form of table when many records match the criteria.
    •     Table control gives user the feeling of an actual table.
    •     You can scroll through the table vertically and horizontally.
    •     You can select rows and columns
    •     Resize the width of a column
    •     You can have separator lines in between rows and columns
    •     Automatic resizing of the table when the user resizes the window.
    In general table control includes all the features of an actual table and user gets the feeling that he is actually working with table. You can update information in table control and it can be updated in the database table by writing code for it.
    Steps associated for creating complete screen table are as follows:
    •     Declaration of table control in module pool program.
    •     Designing of table control on the screen.
    •     Passing data to table in flow logic.
    Declaring of Table Control in the Module Pool Program
    Syntax
    Controls TCI type Tableview using screen <screen no.>
    When you use table control in a screen you must declare the structure in module pool program. Important fields of tableview are as follows:
    •     Lines – number of displayable rows in a table.
    •     Top_line – the row of table where the screen displays start.
    •     Current_line – The row currently being processed inside a loop.
    When you process the table control in flow logic depending upon where you want to start display of rows, you need to use these variables.
    Designing Table Control on Screen
    •     To design table control on the screen, you need to click on Table in control bar and place it on the screen. You can adjust the length and width of table control.
    •     Name the table control. (Here you need to use same name which you have used for declaration of table control in module pool program)
    •     From dictionary object, select table fields and place them in the table control.
    Passing data to Table Control
    As already mentioned, table controls are tables but are treated like loops. Usually transfer of data from program to screen is automatic. But in case of table control, transfer of data is not automatic. You need to explicitly transfer the data to table control. ABAP/4 provides loop statement, which is associated with flow logic to transfer the data. Because table control is treated like a loop, data from where it is transferred should be a loop. You cannot transfer the data by only select statement; you need to put the data into internal table. ABAP/4 provides the LOOP statement, which is associated with the flow logic and allows you to loop through the table control and internal tables. In between LOOP-ENDLOOP, you can use most of the flow logic keywords like field values.  Module etc.
    You need to code a LOOP statement in both PBO and PAI event of the screen. With LOOP statement, you can transfer the data from program to table control and vice versa.  That is, if user updates the value in the table control, you can update database table with its value. And this can be done in PAI event. So even if you are not updating database table through the table control, you need to put the LOOP statement in the PAI event also.
    Syntax
    PBO.
    LOOP AT <internal table> with control <table control name> cursor <scroll variable>
    PAI.
    Loop at itab.
    Proper usage of Table Control is as follows:
    In flow logic.
    PBO.
    LOOP AT ITAB WITH CONTROL TC1 CURSOR TC1-TOP_LINE.
    MODULE ASSIGN.
    ENDLOOP.
    PAI.
    LOOP AT ITAB.
    ENDLOOP.
    Considering, we have following fields in table control and the screen looks like this:
    In module pool program
    CONTROL TC1 Type tableview using screen 200.
    Module assign.
    Sflight – carrid = itab – carrid.
    Sflight - connid= itab -  connid.
    Sflight - fldate= itab – fldate.
    Endmodule.
    The transfer of the data from program to table control takes place in steps and these steps are as follows:
    •     With LOOP AT statement the first row is picked up and placed in the header of the internal table.
    •     Whatever statements you have in between LOOP-ENDLOOP are executed.  In this case, you have Module statement. In Module statement, value of internal table is assigned to table control field.
    •     The row in internal table is transferred to the first line of the table control as stated in the LOOP AT statement.
    •     The system encounters the ENDLOOP statement and Control is passed to the next line of the internal table.
    •     In the same way, all the records of the internal table are passed to the table control.
    STEP LOOPS
    Step Loops are type of screen table as already mentioned. Step loops are repeated blocks of field in a screen. Each block contains one or more fields and these blocks are repeated. Step loops aren’t like actual table. You can scroll vertically but not horizontally. Three steps are associated with creation of step loops:
    •     Creation of step loops on screen, which includes declaring fields on the screen and then defining the step, loops for these fields.
    •     Passing data to the step loop is exactly similar to the passing of data to table controls.
    •     In step loop, you don’t need to define the step loop as such in the module pool program but the cursor needs to be defined in the program.
    Types of Step Loops
    •     Static – Static Step Loop (SSL) have fixed size that cannot be changed during the runtime. If user resizes the window, the size of the static step loop is not changed.
    •     Dynamic – Dynamic Step Loop (DSL) is variable in size. When the user resizes the window, the system increases or decreases the number of the step loop blocks. 
    You can have only one dynamic step loop and can have as many static loops in your    transaction.
    Programming with the Static and dynamic step loop is exactly same.  For the system or for the user it doesn’t make any difference whether it is static or dynamic step loop.  Only attribute, which you fix during designing of the step loop, is type attribute for step loop F for fixed i.e static and V for variable i.e. dynamic.
    Writing code for Step Loop in the flow logic.
         PBO.
              Loop at itab cursor cl.
              Module set.
             Endloop.
         PAI.     
              Loop at itab.
              Endloop.
    Empty loop is must for both table control and step loop
    LOOP AT statement for step loops and Table controls is similar. Loop At statement transfers the data to screen table. You need to have the Module to assign the values for the screen table.
    In module pool program you need to define the cursor.
    Date:   CL TYPE   i.
    Cursor parameter tells which line of step loop display should start.
    “Module Set” in module pool program assigns the values to step loop fields, which is similar to table controls.               
    Branching to List Processing
    Switching To List Mode
    You can display a list within a transaction.
    You can produce a list from module pool program by using the command
    Leave to List-Processing.
    This statement switches the system from dialog mode to list mode. And from this point onwards until you return to dialog mode, you can use all the normal report statement like write, select or any other event.
    Returning back from LIST mode
    You can return back to dialog mode by clicking the BACK button.
    You can have your GUI status and write code for the same. You can include the command LEAVE LIST-PROCESSING. When the system reaches this command, it leaves the list mode and returns to the dialog mode.
    Help & Value Request
    In any transaction, When the user presses F1 or ? on a field, System provides the help  facility for that particular field. In dialog program, when F1 is pressed, help provided by R3 system is sourced from data element documentation. If this documentation is not present for that particular field or if user needs to display additional information for that particular field, then user defined help can be provided through PROCESS ON HELP REQUEST.
    In ABVP/4 help can be provided to the user by:
    Data element documentation: The F1 help can be enhanced, by adding an additional text for the data element in ABAP/4 dictionary.
    It can be done with the help of following steps:
    Place cursor on the screen field,
    GOTO &#61664; DOCUMENTATION &#61664; DATA ELEMENT DOCUMENT
    You can now extend the existing help.
    USING THE PROCESS ON HELP-REQUEST.
    If you don’t have this event in a program, then the documentation of the field in the ABAP/4 dictionary is taken into consideration. If this event exits in the program then it is executed.
    Process on HELP-REQUEST event
    This event is triggered when user presses F1 on a screen field. You need to handle this event in flow-logic by specifying the fields and attaching the module to it.
    Syntax
    PROCESS ON HELP –REQUEST.
    FIELD SFLIGHT-CARRID MODULE HELP-FOR-CARRID.
    In module pool program
    MODULE HELP.
    Write   : `This is field is from sflight table’
    Write   : /  ‘It is of four Character’.
    ENDMODULE.
    When the user presses F1 on this particular field, then this message will be displayed on the screen.
    Value Request
    Whenever the user presses F4 on the screen field list of possible values, particular fields are displayed. If the standard value-help is inadequate or if you want to display additional fields or with different combination of fields, developer can program this in PROCESS ON VALUE-REQUEST event in the flow-logic and subsequent module in the module pool program. When the user presses F4, list of possible values are displayed either from matchcode objects or check table or help view or domain. Each one of them is explained briefly.
    Matchcode objects: Are aggregated dictionary objects and detailed procedure to create these objects is explained in the later part of the material.
    Check Table:  If a check table is assigned to the table field and if the user presses F4 for that particular field, then all the key fields are displayed.
    Domain Values: The values defined in the domain are displayed. These values are set in domain when the domain is created in the dictionary.
    Help views:  In cases where the check table is not sufficient, you can create a help view with this check table, which gives additional information like explanatory text for the fields of the check table.
    PROCESS ON VALUE_REQUEST.
    Each time the user presses F4 on the screen field, following algorithm is called internally.
    When the user presses F4 on flight number, the following screen is displayed.
    The screen displayed is pop-up screen and code for the flow logic and module is written below:
    Flow-logic code

  • Dialog Programs Needed!

    Hi all!
        Pls give any dialog programs to prepare it should contains
          Branching to screens
           Error Handling
         Table Control
         Leaving to List Processing
          if possibe send it to <b>[email protected]</b>
      Looking for your Response
      THANKS
       Rahul.

    Hi,
    Check these links.
    http://wiki.ittoolbox.com/index.php/FAQ:What_is_module_pool_program_in_abap%3F
    http://help.sap.com/saphelp_46c/helpdata/en/35/26b1aaafab52b9e10000009b38f974/content.htm
    http://sap.mis.cmich.edu/sap-abap/abap09/sld011.htm
    http://sap.mis.cmich.edu/sap-abap/abap09/index.htm
    http://www.geocities.com/ZSAPcHAT
    http://www.allsaplinks.com/files/using_table_in_screen.pdf
    http://help.sap.com/saphelp_webas630/helpdata/en/9f/db9cdc35c111d1829f0000e829fbfe/content.htm
    http://www.sapdevelopment.co.uk/dialog/dialoghome.htm
    http://www.sap-img.com/
    http://help.sap.com/saphelp_46c/helpdata/en/08/bef2dadb5311d1ad10080009b0fb56/content.htm
    http://www.sapgenie.com/links/abap.htm
    http://help.sap.com/saphelp_nw04/helpdata/en/c9/5472fc787f11d194c90000e8353423/frameset.htm
    You can also check the transaction ABAPDOCU which gives you lot of sample programs.
    Also you can see the below examples...
    Go to se38 and give demodynpro and press F4.
    YOu will get a list of demo module pool programs.
    One more T-Code is ABAPDOCU.
    YOu can find more examples there.
    See the prgrams:
    DEMO_DYNPRO_TABLE_CONTROL_1 Table Control with LOOP Statement
    DEMO_DYNPRO_TABLE_CONTROL_2 Table Control with LOOP AT ITAB
    http://www.geocities.com/ZSAPcHAT
    http://www.allsaplinks.com/files/using_table_in_screen.pdf
    REPORT ZBHMOD1 .
    DATA:OKCODE1 LIKE SY-UCOMM,
    OKCODE2 LIKE SY-UCOMM.
    DATA:N1(10) TYPE N,N2(10) TYPE N,RES(12) TYPE N.
    MODULE USER_COMMAND_1000 INPUT.
    CASE OKCODE1.
    WHEN 'NEXT'.
    RES = N1 + N2.
    SET SCREEN 1001.
    WHEN 'CLEA'.
    CLEAR:N1,N2.
    WHEN 'BACK'.
    SET SCREEN '0'.
    ENDCASE.
    ENDMODULE. " USER_COMMAND_1000 INPUT
    MODULE STATUS_1000 OUTPUT.
    SET PF-STATUS 'xxxxxxxx'.
    SET TITLEBAR 'TIT1'.
    ENDMODULE. " STATUS_1000 OUTPUT
    MODULE USER_COMMAND_1001 INPUT.
    CASE OKCODE2.
    WHEN 'BACK'.
    SET SCREEN 1000.
    ENDCASE.
    ENDMODULE. " USER_COMMAND_1001 INPUT
    MODULE STATUS_1001 OUTPUT.
    SET PF-STATUS 'xxxxxxxx'.
    SET TITLEBAR 'TIT2'.
    ENDMODULE. " STATUS_1001 OUTPUT
    FLOW LOGIC:
    PROCESS BEFORE OUTPUT.
    MODULE STATUS_1000.
    PROCESS AFTER INPUT.
    MODULE USER_COMMAND_1000.
    PROCESS BEFORE OUTPUT.
    MODULE STATUS_1001.
    PROCESS AFTER INPUT.
    MODULE USER_COMMAND_1001.
    2)
    REPORT ZBHMOD2.
    DATA: OKCODE1 TYPE SY-UCOMM,
    OKCODE2 TYPE SY-UCOMM,
    ENAME(10) TYPE C,
    DNAME(10) TYPE C.
    MODULE STATUS_1000 OUTPUT.
    SET PF-STATUS 'xxxxxxxx'.
    SET TITLEBAR 'TIT1'.
    ENDMODULE. " STATUS_1000 OUTPUT
    MODULE STATUS_1001 OUTPUT.
    SET PF-STATUS 'xxxxxxxx'.
    SET TITLEBAR 'TIT2'.
    ENDMODULE. " STATUS_1001 OUTPUT
    MODULE USER_COMMAND_1000 INPUT.
    CASE OKCODE1.
    WHEN 'BACK'.
    SET SCREEN '0'.
    WHEN 'NEXT'.
    DNAME = ENAME.
    SET SCREEN '1001'.
    ENDCASE.
    ENDMODULE. " USER_COMMAND_1000 INPUT
    MODULE USER_COMMAND_1001 INPUT.
    CASE OKCODE2.
    WHEN 'BACK'.
    SET SCREEN '1000'.
    ENDCASE.
    ENDMODULE. " USER_COMMAND_1001 INPUT
    FORM ON_CTMENU_FORM USING ZDEMO1 TYPE REF TO CL_CTMENU.
    CALL METHOD ZDEMO1->LOAD_GUI_STATUS
    EXPORTING
    PROGRAM = 'ZDEMO1'
    STATUS = 'ZDEMO1'
    MENU = ZDEMO1.
    ENDFORM. " ON_CTMENU_FORM
    FLOW LOGIC:
    PROCESS BEFORE OUTPUT.
    MODULE STATUS_1000.
    PROCESS AFTER INPUT.
    MODULE USER_COMMAND_1000.
    PROCESS BEFORE OUTPUT.
    MODULE STATUS_1001.
    PROCESS AFTER INPUT.
    MODULE USER_COMMAND_1001.
    Every Screen has a pbo and a pai.
    Screen elements are the textbox, buttons, radio buttons and check boxes .....
    If we want to pass data from a abap program to a screen element, we have to create a variable with the name we have given in the screen.So whatever the value is present in that variable is reflected on to the screen element.
    Here is an example :
    Using subscreens and some of the screen elements
    REPORT demo_dynpro_subscreens.
    DATA: ok_code TYPE sy-ucomm,
    save_ok TYPE sy-ucomm.
    DATA: number1(4) TYPE n VALUE '0110',
    number2(4) TYPE n VALUE '0130',
    field(10) TYPE c, field1(10) TYPE c, field2(10) TYPE c.
    CALL SCREEN 100.
    MODULE status_100 OUTPUT.
    SET PF-STATUS 'SCREEN_100'.
    ENDMODULE.
    MODULE fill_0110 OUTPUT.
    field = 'Eingabe 1'(001).
    ENDMODULE.
    MODULE fill_0120 OUTPUT.
    field = field1.
    ENDMODULE.
    MODULE fill_0130 OUTPUT.
    field = 'Eingabe 2'(002).
    ENDMODULE.
    MODULE fill_0140 OUTPUT.
    field = field2.
    ENDMODULE.
    MODULE cancel INPUT.
    LEAVE PROGRAM.
    ENDMODULE.
    MODULE save_ok INPUT.
    save_ok = ok_code.
    CLEAR ok_code.
    ENDMODULE.
    MODULE user_command_0110 INPUT.
    IF save_ok = 'OK1'.
    number1 = '0120'.
    field1 = field.
    CLEAR field.
    ENDIF.
    ENDMODULE.
    MODULE user_command_0130 INPUT.
    IF save_ok = 'OK2'.
    number2 = '0140'.
    field2 = field.
    CLEAR field.
    ENDIF.
    ENDMODULE.
    MODULE user_command_100 INPUT.
    CASE save_ok.
    WHEN 'SUB1'.
    number1 = '0110'.
    WHEN 'SUB2'.
    number1 = '0120'.
    CLEAR field1.
    WHEN 'SUB3'.
    number2 = '0130'.
    WHEN 'SUB4'.
    number2 = '0140'.
    CLEAR field2.
    ENDCASE.
    ENDMODULE.
    flow logic for screen 100
    PROCESS BEFORE OUTPUT.
    MODULE STATUS_100.
    CALL SUBSCREEN: AREA1 INCLUDING SY-REPID NUMBER1,
    AREA2 INCLUDING SY-REPID NUMBER2.
    PROCESS AFTER INPUT.
    MODULE CANCEL AT EXIT-COMMAND.
    MODULE SAVE_OK.
    CALL SUBSCREEN: AREA1,
    AREA2.
    MODULE USER_COMMAND_100.
    flow logic for screen 110
    PROCESS BEFORE OUTPUT.
    MODULE FILL_0110.
    PROCESS AFTER INPUT.
    MODULE USER_COMMAND_0110.
    flow logic for screen 120
    PROCESS BEFORE OUTPUT.
    MODULE FILL_0120.
    PROCESS AFTER INPUT.
    flow logic for screen 130
    PROCESS BEFORE OUTPUT.
    MODULE FILL_0130.
    PROCESS AFTER INPUT.
    MODULE USER_COMMAND_0130.
    flow logic for screen 140
    PROCESS BEFORE OUTPUT.
    MODULE FILL_0140.
    PROCESS AFTER INPUT.
    Regard,
    Priyanka.

  • 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.
    <u><i><b>
    What is a user dialog?</b></i></u>
    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.
    <u><i><b>Need of dialog programming</b></i></u>
    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.
    <u><i><b>Why dialog programming is also known as module pool?</b></i></u>
    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 don’t. 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
    <u><i><b>OVERVIEW</b></i></u>
    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.
    <u><i><b>What is a user dialog?</b></i></u>
    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.
    <u><i><b>Need of dialog programming</b></i></u>
    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.
    <u><i><b>
    Why dialog programming is also known as module pool?</b></i></u>
    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.
    <i><b>VARIOUS COMPONENTS OF A DIALOG PROGRAM</b></i>
    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.
    <u><i><b>
    Components of a dialog program</b></i></u>
    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

Maybe you are looking for