Structure of dialog programming?

Hi All,
what is the stucture of dialog program?
Regards,
Waseem

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.
http://sap.mis.cmich.edu/sap-abap/abap09/sld007.htm

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/

Dialog programming, data being washed out in TAB Control

Hi,
     i am working on dialog programming , in which i am using Table Control for user input (data is not coming from database table) . everything is going well till assignment of data to internal table but when
control goes to PBO by any means like pressing ENTER etc. then data being washed out.
PROCESS BEFORE OUTPUT.
MODULE TC_CONTROL.
LOOP AT it_data
         INTO wa_data
         WITH CONTROL tc_control
         CURSOR tc_control-current_line.
    MODULE tc_control_get_lines.
ENDLOOP.
PROCESS AFTER INPUT.
LOOP AT IT_DATA.
    CHAIN.
      FIELD WA_DATA-FREPS_N.
      FIELD wa_data-TOEPS_N.
      FIELD wa_data-PRCH_A.
      FIELD wa_data-SRVC_AMT .
      FIELD wa_data-ACCNT_C.
      FIELD wa_data-AMT_D.
      FIELD wa_data-NARR_X.
      FIELD wa_data-CRPRD_N.
      MODULE tc_control_modify ON CHAIN-REQUEST.
    ENDCHAIN.
ENDLOOP.
*Abap program
MODULE TC_CONTROL OUTPUT.
DESCRIBE TABLE it_data LINES tc_control-lines.
ENDMODULE.                 " TC_CONTROL OUTPUT
CONTROLS: TC_CONTROL TYPE TABLEVIEW USING SCREEN 1000,
          TC_CONTROL1 TYPE TABLEVIEW USING SCREEN 1000.
DATA:     G_TC_CONTROLS_LINES LIKE SY-LOOPC,
          G_TC_CONTROLS_LINES1 LIKE SY-LOOPC.
*&      Module tc_control_get_lines OUTPUT
      text
MODULE tc_control_get_lines OUTPUT.
g_tc_controls_lines = sy-loopc.
move-corresponding it_data to wa_data.
ENDMODULE.                 " tc_control_get_lines OUTPUT
MODULE tc_control_modify INPUT.
move-corresponding wa_data to it_data.
MODIFY it_data
    FROM wa_data
    INDEX tc_control-current_line.
append it_data.
clear it_data.
ENDMODULE.                 " tc_control_modify INPUT
Please suggest me any clue.
Thanks in advance
vijay dwivedi

Hi ,
I have understood the problem.
In your ABAP code replace all the occurrrences of wa_data with the structurename.
Use the TABLES keyword to declare the structure .That structure will be same as
reference table of the table control .
Here the structure is SPFLI.
Check the bellow code , it will resolve the issue.
ABAP code - -
program zsdn.
tables spfli. " Declare the structure
data : it_data like table of spfli with header line,
*wa_data TYPE spfli, " commented
w_i type i.
*CONTROLS TC_CONTROL TYPE TABLEVIEW USING SCREEN 100.
controls: tc_control type tableview using screen 1000,
tc_control1 type tableview using screen 1000.
data: g_tc_controls_lines like sy-loopc,
g_tc_controls_lines1 like sy-loopc.
module tc_control output.
describe table it_data lines tc_control-lines.
endmodule. " TC_CONTROL OUTPUT
module tc_control_get_lines output.
g_tc_controls_lines = sy-loopc.
move-corresponding it_data to spfli.
endmodule. " tc_control_get_lines OUTPUT
module tc_control_modify input.
move-corresponding spfli to it_data.
modify it_data
from spfli
index tc_control-current_line.
append it_data.
clear it_data.
endmodule. " tc_control_modify INPUT
module status_0100 output.
set pf-status 'STAT'.
* SET TITLEBAR 'xxx'.
endmodule.                 " STATUS_0100 OUTPUT
module user_command_0100 input.
case sy-ucomm.
    when 'BACK' or 'EXIT' or 'CANCEL'.
      leave to screen 0.
endcase.
endmodule.                 " USER_COMMAND_0100 INPUT
*&      Module POPLATE_TABLE OUTPUT
*       text
module poplate_table output.
if it_data is initial.
    select * from spfli into table it_data.
endif.
endmodule.                 " POPLATE_TABLE OUTPUT
Screen code (Scr no 1000) - -
PROCESS BEFORE OUTPUT.
MODULE status_0100.
MODULE poplate_table.
MODULE tc_control.
LOOP AT it_data WITH CONTROL tc_control CURSOR w_i.
    MODULE tc_control_get_lines.
ENDLOOP.
PROCESS AFTER INPUT.
MODULE user_command_0100.
LOOP AT it_data.
    MODULE tc_control_modify ON CHAIN-REQUEST.
*    ENDCHAIN.
ENDLOOP.
Regards
Pinaki

Select option in Dialog program screen

Hi friends,
do we have any way to get a select option displayed in dialog programming ?
or
create a screen field with the properties of a select option in dialog screen ?
or
any standard function module to support this scenario ?
Thanks and Regards
Sakthi.

Hi,
i don't know you checked it or not, but i am able to do it, i send the screen shot also to you check it..
it is possible,with some coding also check it once...
REPORT ZTEST_SCREEN .
DATA : BEGIN OF IT_DYNPFIELDS OCCURS 3.
 INCLUDE STRUCTURE DYNPREAD.
DATA : END OF IT_DYNPFIELDS.
DATA: TEST(10) TYPE C.
RANGES: R_UNAME FOR SY-UNAME.
DATA: V_USERNAME LIKE SY-UNAME.
DATA : V_PROG LIKE D020S-PROG VALUE 'ZTEST_SCREEN',
 V_DNUM LIKE D020S-DNUM VALUE '0100'.
CALL SCREEN 100.
*& Module STATUS_0100 OUTPUT
* text
MODULE STATUS_0100 OUTPUT.
SET PF-STATUS 'TEST'.
* SET TITLEBAR 'xxx'.
ENDMODULE. " STATUS_0100 OUTPUT
*& Module USER_COMMAND_0100 INPUT
* text
MODULE USER_COMMAND_0100 INPUT.
CASE SY-UCOMM.
 WHEN 'BACK'.
 LEAVE TO SCREEN 0.
ENDCASE.
ENDMODULE. " USER_COMMAND_0100 INPUT
*& Module GET_CURSOR_USERNAME INPUT
* text
MODULE GET_CURSOR_USERNAME INPUT.
REFRESH IT_DYNPFIELDS.
CLEAR IT_DYNPFIELDS.
MOVE 'V_USERNAME' TO IT_DYNPFIELDS-FIELDNAME.
APPEND IT_DYNPFIELDS.
CLEAR IT_DYNPFIELDS.
CALL FUNCTION 'DYNP_VALUES_READ'
 EXPORTING
 DYNAME = V_PROG
 DYNUMB = V_DNUM
 TRANSLATE_TO_UPPER = 'X'
 TABLES
 DYNPFIELDS = IT_DYNPFIELDS
 EXCEPTIONS
 INVALID_ABAPWORKAREA = 1
 INVALID_DYNPROFIELD = 2
 INVALID_DYNPRONAME = 3
 INVALID_DYNPRONUMMER = 4
 INVALID_REQUEST = 5
 NO_FIELDDESCRIPTION = 6
 INVALID_PARAMETER = 7
 UNDEFIND_ERROR = 8
 DOUBLE_CONVERSION = 9
 STEPL_NOT_FOUND = 10
 OTHERS = 11.
IF SY-SUBRC = 0.
 READ TABLE IT_DYNPFIELDS WITH KEY FIELDNAME = 'V_USERNAME'.
 IF SY-SUBRC = 0.
 V_USERNAME = IT_DYNPFIELDS-FIELDVALUE.
 ENDIF.
ENDIF.
PERFORM GET_MULTIPLE.
ENDMODULE. " GET_CURSOR_USERNAME INPUT
*& Form GET_MULTIPLE
* text
* --> p1 text
* <-- p2 text
FORM GET_MULTIPLE .
* Dynamically holding Field name
FIELD-SYMBOLS: <FST> TYPE STANDARD TABLE.
IF R_UNAME[] IS INITIAL.
 IF NOT V_USERNAME IS INITIAL.
 R_UNAME-SIGN = 'I'.
 R_UNAME-OPTION = 'EQ'.
 R_UNAME-LOW = V_USERNAME.
 APPEND R_UNAME.
 CLEAR R_UNAME.
 ENDIF.
ENDIF.
ASSIGN R_UNAME[] TO <FST>.
CALL FUNCTION 'COMPLEX_SELECTIONS_DIALOG'
 EXPORTING
 TITLE = 'Select Multiple Value'(059)
 TEXT = 'Finish Group'(058)
 SIGNED = 'X'
 LOWER_CASE = ' '
 NO_INTERVAL_CHECK = 'X'
 JUST_DISPLAY = ' '
 JUST_INCL = 'X'
 TABLES
 RANGE = <FST>
 EXCEPTIONS
 NO_RANGE_TAB = 1
 CANCELLED = 2
 INTERNAL_ERROR = 3
 OTHERS = 4.
IF SY-SUBRC = 0.
 READ TABLE R_UNAME INDEX 1.
 IF SY-SUBRC = 0.
 V_USERNAME = R_UNAME-LOW.
 ENDIF.
ENDIF.
ENDFORM. " GET_MULTIPLE
Flow loogic....
PROCESS BEFORE OUTPUT.
MODULE STATUS_0100.
PROCESS AFTER INPUT.
MODULE USER_COMMAND_0100.
PROCESS ON VALUE-REQUEST.
*- To capture the cursor and for f4
FIELD V_USERNAME MODULE GET_CURSOR_USERNAME.
in screen i have one field v_username
for that field do this
double click on field which you want to make it as select option, it will display the attributes screen, in that click on program attributes button , now go to poss. entries in the dropdown choose 1 show at selection.
Regards
vijay

Help needed to write a dialog program

Hello ABAP Gurus,
I am very much new to ABAP Programming.
Can anybody help me to write a simple Dialog Program ??
I have a database table.
I have created a screen with screen painter, and kept some input fields & a push button in it.
I want to fill the database table with the data entered into the fields on the screen.
When the user enters the data and presses the PUSH BUTTON then that data record should be stored into the Database table.
So what kinda code I have to write in PAI (Process After Input), to achieve this functionality ??
The help will be greatly appreciated.
Thanks in advance
Best regards
Ravi
Edited by: Ravi Kiran on Oct 28, 2009 2:17 PM

It's easy:
In PAI you have do an insert into a database table, following the steps:
1.on PAI create a module: for exemple Zwrite_table.
2. inside Zwrite_table code as follow:
move var1 to wa_table-var1.
move var2 to wa_table-var2.
move var3 to wa_table-var3. etc etc
insert table ztable from wa_table.
P.s. ztable is a database table.
wa_table is a structure that have the same structure of ztable.
var1 var2 var3 etc is a variable inside your dynpro.
regards,
Roberto.

Small issue in dialog program

Hello all,
i have a requirement in dialog programming.
I have to modify a record a record which exist in zatble.
For each record , i have a header info, item details.
for header iam ok , i can use modify.
for item details i have like
itemno material materialdesc quantity
1 m1 pqr 12
2 m2 def 9
3 m3 abc 2
4 m4 xyz 1
item no and material are my primary keys.
so iam retrieving this data from a z table and have to update.
may be i need to delete 3 record and modify 2 record,i would do that based on the selectionfrom table control
itemno material materialdesc quantity
1 m1 pqr 12
2 m2 def 19
3 m4 xyz 1
now i have deleted 3 record and modifed 2 with increase in quantity and the itemno are changed
I have ths data in my internal table.
iAM USING MODIFY STATEMNT WHEN I SAVE THE DATA INTO DATABASE TABLE.
i SEE THE FOLLOWING DAT AIN MY ZTABLE
1 m1 pqr 12
2 m2 def 19
3 m3 abc 2
4 m4 xyz 1
3 m4 xyz 1
THOGHT I NEED ONLY THESE DATA TO BE PRESENT IN MY ZTABLE
1 m1 pqr 12
2 m2 def 19
3 m4 xyz 1
Any help or suggestions regarding this
Thanks
Suchitra

Hi suchitra,
do one thing ,,
first task
1.first of all select all the contents of ztable based on primary keys into a internal table itab.
1 m1 pqr 12
2 m2 def 9
3 m3 abc 2
4 m4 xyz 1
2. in ur m-pool table control u r performing the operations like delete and modify to the table control GET THE CONTENTS INTO UR FINAL TABLE JTAB ..Lets say
This is ur final jtab.
1 m1 pqr 12
2 m2 def 19
4 m4 xyz 1
NOW PERFORM COMPARISIONS,
3. LOOP AT ITAB.
 READ TABLE JTAB WITH KEY ITEMNO = ITAB-ITEMNO
 AND MATNR = JTAB-MATNR
 And menge = jtab -menge
 IF SY-SUBRC <> 0.
 ITAB-ITEMNO = JTAB-ITEMNO.
 ITAB_MATNR = JTAB-MATNR.
 ITAB_MATDESC = JTAB_MATDESC
 ITAB_MENGE = JTAB_MENGE
 MODIFY ITAB. TRANSPORTING
 ENDIF.
 ENDLOOP.
THIS WILL COVER RECORD 2 IN UR ITAB CHANGES ARE OK ..
second task ..
4. NOW SINCE U HAVE DELETED RECORD 3 ,, PLACE IN AN EXTRA FILED IN THE JTAB STRUCTURE
LIKE CHAR TYPE C, SAME HAS TO BE IN ITAB ALSO
AND MAKE IT X WHEN EVER U DELETE IT IN TABLE CONTROL
LIKE THIS THE O/P IM EXPECTING HERE IS IN JTAB
1 m1 pqr 12
2 m2 def 19
3 m3 abc 2 x
4 m4 xyz 1
LOOP AT ITAB.
 READ TABLE JTAB WITH KEY ITEMNO = ITAB-ITEMNO
 AND MATNR = JTAB-MATNR
IF JTAB-CHAR = X.
 ITAB-ITEMNO = JTAB-ITEMNO.
 ITAB_MATNR = JTAB-MATNR.
 ITAB_MATDESC = JTAB_MATDESC
 ITAB_MENGE = JTAB_MENGE
 ITAB-CHAR = JTAB-CHAR
 MODIFY ITAB. TRANSPORTING
 ENDIF.
ENDLOOP.
NOW THE ITAB CONTENT IS
1 m1 pqr 12
2 m2 def 19
3 m3 abc 2 x
4 m4 xyz 1
My suggestion to u is modify the ztable from itab .
Without deleting entry 3
This will solve ur prob .
Cause when u do a select next time
Select entries where char <> X
Which will fetch u
1 m1 pqr 12
2 m2 def 19
4 m4 xyz 1
Try to bring the logic in a single loop this will do
i have split this for ur understanding ....

Search help in dialog program

Hi all,
Fora search help in dialog program.
I HAVE TO GET SEARCH FOR A FIELD ZID ON APARTICULAR SCREEN BASED ON DATA, MODIFIED BY AND A PLANT..
I HAVE A RECORD IN ONE MY ZTABLE.
I HAVE TO GET THAT BY SEVERAL SEARCH PARAMETERS SAY BY DATE , MODIFIED BY,PLANT ETC.
each user has been assigned a plant , so in search he has to get records belonging to that plant.
so i cannot include plant in my search help, because user may type in other plant.
so i tried two ways
1) i created a search help in se11 including the plant field again the problem arises if the user types a different plant.
so i want to know whether we can apassa value to plant field in search help(i.e the plant assigned to the user),
i have this kind of thing in some standard t -code i.e especially for searching material , the plant field in search help was filled by one plant.
this should be one of the solution
2)I tried to write a code in pov of program code.
this is how my code looks.
DATA : BEGIN OF ITAB OCCURS 0.
 INCLUDE STRUCTURE ZXXX.
DATA : END OF ITAB.
ITAB HAS FIELDS ID, DATE , MODIFIEDBY , PLANT.
USER_PLANT = 'ABC'.
SELECT * FROM ZXXX INTO TABLE ITAB WHERE PLANT = USER_PLANT.
CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'
EXPORTING
DDIC_STRUCTURE = ' '
 RETFIELD = 'ZID'
PVALKEY = ' '
DYNPPROG = ' '
DYNPNR = ' '
DYNPROFIELD = ' '
STEPL = 0
 WINDOW_TITLE = 'TEST'
VALUE = ' '
 VALUE_ORG = 'S'
MULTIPLE_CHOICE = ' '
DISPLAY = ' '
CALLBACK_PROGRAM = ' '
CALLBACK_FORM = ' '
TABLES
 VALUE_TAB = ITAB
FIELD_TAB =
 RETURN_TAB = IT_RETURN4
DYNPFLD_MAPPING =
EXCEPTIONS
PARAMETER_ERROR = 1
NO_VALUES_FOUND = 2
OTHERS = 3
IF SY-SUBRC <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
 WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
if sy-subrc = 0.
 clear itab.
 read table it_return4 index 1.
 ZXXX-ZID = it_return4-fieldval.
endif.
THIS WORKS FINE , BUT HE CANNOT SEARCH BASED ON DATE AND MODIFIEDBY
ALL i want is is get a pop up window and should be able to search based on data and modifiedby for a predifined plant.
I hope iam clear.
Thanks

Hi,
Create a FM with the following code..The interface is defined in the code..
In the Function module top include add the following code.
TYPE-POOLS: shlp, vrm.
IN this code I am deleting the records that are not of the currency USD...
Do the same thing for your requirement...
FUNCTION Y_SEARCH_HELP_EXIT.
""Local interface:
*" TABLES
*" SHLP_TAB TYPE SHLP_DESCR_TAB_T
*" RECORD_TAB STRUCTURE SEAHLPRES
*" CHANGING
*" REFERENCE(SHLP) TYPE SHLP_DESCR_T
*" REFERENCE(CALLCONTROL) LIKE DDSHF4CTRL STRUCTURE DDSHF4CTRL
where z_test is my z table..
DATA: ITAB LIKE Z_TEST OCCURS 0 WITH HEADER LINE.
ITAB[] = RECORD_TAB[].
IF NOT RECORD_TAB[] IS INITIAL.
DELETE ITAB WHERE WAERS <> 'USD'.
RECORD_TAB[] = ITAB[].
ENDIF.
ENDFUNCTION.
Thanks,
Naren

Triggering a workflow through a dialog program

I tried to trigger a workflow through a dialog program using FM. I also created BOR and workflow(SWDD). The dialog program basically deletes a sales order and then a workflow should trigger. I am not able to see the email. Am I missing anything here?
Pls find below the coding..'ZCSS_SO1' is the BO.
Data : g_objtype LIKE SWR_STRUCT-OBJECT_TYP,
G_OBJKEY LIKE SWR_STRUCT-OBJECT_KEY,
G_EVENT LIKE SWR_STRUCT-EVENT.
data begin of l_input_container occurs 0.
include structure swcont.
data end of l_input_container.
data: v_vbeln like vbak-vbeln.
g_objtype = 'ZCSS_SO1'.
g_event = 'DELETE'.
G_OBJKEY = 'SALESDOCUMENT'.
CALL FUNCTION 'SWC_ELEMENT_SET'
EXPORTING
element = 'ELEMENT'
field = 'VALUE'
tables
container = l_input_container.
CALL FUNCTION 'SWE_EVENT_CREATE_IN_UPD_TASK'
EXPORTING
objtype = g_objtype
objkey = G_OBJKEY
event = g_event
tables
event_container = l_input_container.
commit work.

Hi Chandri,
You can firstly check whether the code you have written below is triggering the BO event or not by switching on the trace using transaction SWELS , then running the transaction (dialog program mentioned below). After, switch off the trace and then view the trace from transaction SWEL.
Your BO and event should show up in the trace.
Regards,
Aditya
p.s. also for the mail, check what method u are using?

MULTIPLE SELECTION IN DIALOG PROGRAMMING

Hello exports,
I need to provide an interface to user where he can Put multiple selected invoice number at a time. (Like multiple selection in select option). It should be done in dialog programming.
plz suggest me .

Hai ,
You can use RANGES or can use TYPE RANGE OF while declaring.
For eg:
DATA:it_invoice    TYPE RANGE OF vbrk-vbeln,
.         wa_invoice LIKE   LINE     OF it_invoice.
Now u need a bit of coding,
wa_invoice -sign   = 'I'.
wa_invoice -option = 'BT'. i.e between
r_carrid_line-low    = your screen fieldname inwhich the lower limit was selected
r_carrid_line-high   = your screen fieldname inwhich the higher limit was selected.
APPEND wa_invoice TO it_invoice.
Now u can use this internal table IT_INVOICE in query using operator IN in the WHERE caluse as u use with select-options.
Or you can create a report program which has only a selection screen
You can EXPORT the object(select option name) to ur dialog program using IMPORT/EXPORT MEMORY ID .
But you need to declare the select options in ur dialog program with the same name and the structure
DATA: BEGIN OF rtab OCCURS {10|n},
             sign   TYPE c LENGTH 1,
             option TYPE c LENGTH 2,
             low    LIKE dobj,
             high   LIKE dobj,
      END OF rtab.
Thanks,
Neeraj

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 doesnt 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  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  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  Flow logic
Or
From Screen attribute screen  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 users 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 dont 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 doesnt 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 donts 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 arent 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 dont 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 doesnt 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  DOCUMENTATION  DATA ELEMENT DOCUMENT
You can now extend the existing help.
USING THE PROCESS ON HELP-REQUEST.
If you dont 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 programming (non-web based)

We have been running SAP for a number of years and have a number of custom tables and custom ABAP report programs. At this point we use spreadsheet uploads and sm30 to maintain our custom tables. We are now looking at getting into Dialog programming, we will be running these dialog programs with in the SAP GUI not over the internet.
Most of the web sites I have found for dialog programming in ABAP are talking about Web dynpro. Can anyone tell me if there is a difference between Web dynpro and non-web dialog programming?
Thanks,
Jerry

Thanks for the replies this is what I thought.
It is being suggested that we can write a dialog using Web dynpro and have it display and act exactly the same over the internet and within the GUI. So that the user experience is the same no matter which method they use.
This sounds logical to me.
When I read the link I clicked on the dynpro link and then went to up 2 levels to the u2018SAP GUI Technologyu2019 page and found the following:
Although screen programming permits, in principle, the use of the model-view-controller approach, this is not explicitly supported by the Framework or the existing tools. There is therefore a significant mixing of presentation and application logic within a program in most screen-based applications. To achieve better maintainability, you should therefore structure the user interfaces of new ABAP-based applications with Web << OLE Object: Picture (Metafile) >> Dynpro ABAP, even if no use of the Internet is currently intended.
This would imply that that using web dynpro you can create a dialog that looks and acts the same over the internet and within the GUI.
We found a Blog with the title Web Dynpro: Running Web Dynpro Applications over SAPGUI that makes reference to the function module WDY_EXECUTE_IN_PLACE, with a parameter INTERNALMODE = u2018Xu2019 that will allow the screen to be displayed in the SAP GUI.
Then I was directed to SAP NOTE 1098009 which says:
· No SAP GUI support
The use of Web Dynpro ABAP applications inside SAP GUI is not supported due to technical restrictions which may inhibit the correct behavior of applications under some circumstances.
· No support for SAP GUI dynpros
Note that in an input help which is called by Web Dynpro ABAP classic SAP GUI based dynpros are not supported. From NetWeaver 7.0 SP12 onwards there is no longer a program dump, but a message is displayed accordingly, so that the application can be continued.
There seems to be conflicting information out there. Does anyone have any experience with this? Can you please point me to some documentation that will explain if this is possible or not.
Thanks,
Jerry

Differences between ABAP Programming and Dialog Programming

Can any one explain me the Differences between ABAP Programming and Dialog Programming

Hi,
ABAP PROGRAMING:
An ABAP program consists of individual ABAP statements. Each statement begins with a keyword and ends with a period.
PROGRAM FIRST_PROGRAM.
WRITE 'My First Program'.
This example contains two statements, one on each line. The keywords are PROGRAM and WRITE. The program displays a list on the screen. In this case, the list consists of the line "My First Program".
The keyword determines the category of the statement. For an overview of the different categories, refer to ABAP Statements.
You can execute different parts of programs conditionally or in loops using the standard keywords IF, CASE, DO, and WHILE.
When controlling the flow of an ABAP program, remember that the structure of the program is made up of processing blocks that cannot be nested. This section describes how to control the flow of a program within a processing block. The keywords covered here do not allow you to branch outside the processing block in which you use them. You can regard this as internal control of an ABAP program, as opposed to the external control provided by events in the ABAP runtime environment.
To control the internal flow of a processing block, you can use control structures to divide it up into smaller statement blocks according to the principles of structured programming.
DIALOG PROGRAMING:
This is a classical programming method that is based on dynpros and dialog transactions.
Classic Application Programming
Separating the application layer from the presentation layer means that when you run an ABAP application program requiring user interaction, control of the program is continually passed backwards and forwards between these layers. While a screen is ready for input, the corresponding SAP GUI of the presentation layer is active. During this time, the application layer is not active for the application program. Therefore, the ABAP application servers are free for other tasks. Once the user has entered data on the screen, program control passes back to the application layer. Now, the presentation layer is inactive. The SAP GUI is still visible to the user during this time, and it is still displaying the screen, but it cannot accept user input. The SAP GUI does not become active again until the application program has called a new screen and sent it to the presentation server.
Consequently, if you use this method, you need to divide dialog programs into single dialog steps, with each of these steps comprising the programming logic between two successive screens.
REGARDS,
VASAVI.
KINDLY REWARD IF HELPFUL.

How to call a dialog program with return value in another dialog program

Dear All,
How can I call a dialog program with return value from another dialog program?
Regards,
Alok.

Hi Alok,
You can you SET/GET parameters to do this.
This is some information about this.
To fill the input fields of a called transaction with data from the calling program, you can use the SPA/GPA technique. SPA/GPA parameters are values that the system stores in the global, user-specific SAP memory. SAP memory allows you to pass values between programs. A user can access the values stored in the SAP memory during one terminal session for all parallel sessions. Each SPA/GPA parameter is identified by a 20-character code. You can maintain them in the Repository Browser in the ABAP Workbench. The values in SPA/GPA parameters are user-specific.
ABAP programs can access the parameters using the SET PARAMETER and GET PARAMETERstatements.
To fill one, use:
SET PARAMETER ID pid FIELD f.
This statement saves the contents of field f under the ID pid in the SAP memory. The ID pid can be up to 20 characters long. If there was already a value stored under pid, this statement overwrites it. If you double-click pid in the ABAP Editor, parameters that do not exist can be created as a Repository object.
To read an SPA/GPA parameter, use:
GET PARAMETER ID pid FIELD f.
This statement places the value stored under the pid ID into the variable f. If the system does not find any value for pid in the SAP memory, sy-subrc is set to 4. Otherwise, it sets the value to 0.
Thanks,
SriRatna

How to call a Dialog Program from another Dialog Program

Dear All,
How can I call a dialog program with return value from another dialog program?
Regards,
Alok.

Hi Alok,
1. Insted of creating 2 different Dialog program. It's good to create as many screens as you want in same module pool program. Any way you can use the different TCODE for each screen.
2. Another and The best way is to create a function group and then inside function group use the function 2 module... In the function group define a global variable which will be present for both the function group if they are getting executed in sequence. and inside the Function Module call the screens using command " call screen <screenno>".
3. You can use set / get parameter to pass values of a field between two dynpro program.

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

Structure of dialog programming?

Similar Messages

Maybe you are looking for