Call Dialog

[Former Member]

Hi all,

what is the Call Dilog.what is purpose of this call dialog.Call dialog is obsoleted.which statement how can i achieve the functionality of Call Dialog.

Thanks,

Swapna.

[Former Member]

This may be helpful to u

CALL DIALOG

Syntax

CALL DIALOG dialog [ {AND SKIP FIRST SCREEN}

[ {USING bdc_tab MODE mode]}

http://EXPORTING p1 FROM a1 p2 FROM a2 ...

http://IMPORTING p1 TO a1 p2 TO a2 ....

Extras:

1. ... AND SKIP FIRST SCREEN

2. ... USING bdc_tab MODE mode

3. ... EXPORTING p1 FROM a1 p2 FROM a2 ...

4. ... IMPORTING p1 TO a1 p2 TO a2 ...

Effect

The statement CALL DIALOG calls the dialog module whose name is contained in the character-like data object dialog. The data object dialog must contain the name in uppercase. If the dialog module specified in dialog is not found, an exception that cannot be handled is raised.

When calling the dialog module, the assigned ABAP program is loaded in a new internal session. The session of the calling program is still available. In contrast to CALL TRANSACTION, the called program runs in the same SAP LUW as the calling program.

After loading the ABAP program, the event LOAD-OF-PROGRAM is triggered and the screen defined as the initial screen of the dialog module is called. The dialog module is terminated when the corresponding screen sequence terminates upon reaching the next screen with screen number 0 or the program is exited using the statement .

Note

Dialog modules are the only language resource that can be used to open a new session without changing the SAP LUW. Be aware of the following:

The statements COMMIT WORK and ROLLBACK WORK cause database commits or database rollbacks in the called program. However, the procedures registered with CALL FUNCTION IN UPDATE TASK and PERFORM ON {COMMIT|ROLLBACK} are not executed until the execution of the corresponding statements in the calling program.

In the called program, SAP locks are adopted by the caller.

Addition 1

... AND SKIP FIRST SCREEN

Effect

Under the same conditions as for the statement CALL TRANSACTION, this addition surpresses the display of the screen of the initial screen. If the called dialog module has input parameters for the obligatory input fields of the initial screen, they can also be filled using a parameter transfer instead of SPA/GPA parameters.

Addition 2

... USING bdc_tab MODE mode

Effect

This addition controls the called program as in the statement CALL TRANSACTION using the specification of a batch input folder in an internal table bdc_tab of the line type BDCDATA. In this case, only MODE can be used as an addition for the control of the batch input processing.

If a message is sent in the called program, this message is available in the system fields sy-msgid, sy-msgty, sy-msgno, sy-msgv1, ..., sy-msgv4 after the call.

Addition 3

... EXPORTING p1 FROM a1 p2 FROM a2 ...

Addition 4

... IMPORTING p1 TO a1 p2 TO a2 ...

Effect

These additions can be used to assign the appropriate actual parameters a1, a2, ... to the formal parameters p1, p2, ... of the dialog module. The formal parameters of a dialog module are always optional. They can have all data types except for reference types.

When loading the called program, the values of the actual parameters are assigned to the global data objects of the called program that are defined as formal parameters. If this data is associated with screen fields of the same name, they are not overwritten by possible SPA/GPA parameters. If you specify IMPORTING, the system field sy-subrc is implicitly adopted by the called dialog module and unknown formal parameters are ignored by the system.

Note

Outside of classes, the additions FROM a1, FROM a2, ... und TO a1, TO a2, ... in the parameter lists can be omitted if the formal parameters and actual parameters have the same names.

Example

Calling a dialog module DEMO_DIALOG_MODULE which is associated with the program SAPMDEMO_TRANSACTION.

DATA spfli_wa TYPE spfli.

spfli_wa-carrid = 'LH'.

spfli_wa-connid = '0400'.

CALL DIALOG 'DEMO_DIALOG_MODULE'

EXPORTING

spfli-carrid FROM spfli_wa-carrid

spfli-connid FROM spfli_wa-connid

IMPORTING

spfli_wa TO spfli_wa.

Exceptions

Non-Catchable Exceptions

Cause: Parameter name is too long.

Runtime Error: CALL_DIALOG_NAME_TOO_LONG

Cause: The called dialog module is unknown.

Runtime Error: CALL_DIALOG_NOT_FOUND

Cause: The called dialog module contains errors (incorrect entry in table TDCT).

Runtime Error: CALL_DIALOG_WRONG_TDCT_MODE

Cause: No further paging area for parameter transfer available.

Runtime Error: CALL_DIALOG_NO_CONTAINER

Cause: The statement CALL DIALOG ... SCREEN ... PROGRAM ... is not supported.

Runtime Error: CALL_DIALOG_SCREEN/PROGRAM

[Former Member]

This may be helpful to u

CALL DIALOG

Syntax

CALL DIALOG dialog [ {AND SKIP FIRST SCREEN}

[ {USING bdc_tab MODE mode]}

http://EXPORTING p1 FROM a1 p2 FROM a2 ...

http://IMPORTING p1 TO a1 p2 TO a2 ....

Extras:

1. ... AND SKIP FIRST SCREEN

2. ... USING bdc_tab MODE mode

3. ... EXPORTING p1 FROM a1 p2 FROM a2 ...

4. ... IMPORTING p1 TO a1 p2 TO a2 ...

Effect

The statement CALL DIALOG calls the dialog module whose name is contained in the character-like data object dialog. The data object dialog must contain the name in uppercase. If the dialog module specified in dialog is not found, an exception that cannot be handled is raised.

When calling the dialog module, the assigned ABAP program is loaded in a new internal session. The session of the calling program is still available. In contrast to CALL TRANSACTION, the called program runs in the same SAP LUW as the calling program.

After loading the ABAP program, the event LOAD-OF-PROGRAM is triggered and the screen defined as the initial screen of the dialog module is called. The dialog module is terminated when the corresponding screen sequence terminates upon reaching the next screen with screen number 0 or the program is exited using the statement .

Note

Dialog modules are the only language resource that can be used to open a new session without changing the SAP LUW. Be aware of the following:

The statements COMMIT WORK and ROLLBACK WORK cause database commits or database rollbacks in the called program. However, the procedures registered with CALL FUNCTION IN UPDATE TASK and PERFORM ON {COMMIT|ROLLBACK} are not executed until the execution of the corresponding statements in the calling program.

In the called program, SAP locks are adopted by the caller.

Addition 1

... AND SKIP FIRST SCREEN

Effect

Under the same conditions as for the statement CALL TRANSACTION, this addition surpresses the display of the screen of the initial screen. If the called dialog module has input parameters for the obligatory input fields of the initial screen, they can also be filled using a parameter transfer instead of SPA/GPA parameters.

Addition 2

... USING bdc_tab MODE mode

Effect

This addition controls the called program as in the statement CALL TRANSACTION using the specification of a batch input folder in an internal table bdc_tab of the line type BDCDATA. In this case, only MODE can be used as an addition for the control of the batch input processing.

If a message is sent in the called program, this message is available in the system fields sy-msgid, sy-msgty, sy-msgno, sy-msgv1, ..., sy-msgv4 after the call.

Addition 3

... EXPORTING p1 FROM a1 p2 FROM a2 ...

Addition 4

... IMPORTING p1 TO a1 p2 TO a2 ...

Effect

These additions can be used to assign the appropriate actual parameters a1, a2, ... to the formal parameters p1, p2, ... of the dialog module. The formal parameters of a dialog module are always optional. They can have all data types except for reference types.

When loading the called program, the values of the actual parameters are assigned to the global data objects of the called program that are defined as formal parameters. If this data is associated with screen fields of the same name, they are not overwritten by possible SPA/GPA parameters. If you specify IMPORTING, the system field sy-subrc is implicitly adopted by the called dialog module and unknown formal parameters are ignored by the system.

Note

Outside of classes, the additions FROM a1, FROM a2, ... und TO a1, TO a2, ... in the parameter lists can be omitted if the formal parameters and actual parameters have the same names.

Example

Calling a dialog module DEMO_DIALOG_MODULE which is associated with the program SAPMDEMO_TRANSACTION.

DATA spfli_wa TYPE spfli.

spfli_wa-carrid = 'LH'.

spfli_wa-connid = '0400'.

CALL DIALOG 'DEMO_DIALOG_MODULE'

EXPORTING

spfli-carrid FROM spfli_wa-carrid

spfli-connid FROM spfli_wa-connid

IMPORTING

spfli_wa TO spfli_wa.

Exceptions

Non-Catchable Exceptions

Cause: Parameter name is too long.

Runtime Error: CALL_DIALOG_NAME_TOO_LONG

Cause: The called dialog module is unknown.

Runtime Error: CALL_DIALOG_NOT_FOUND

Cause: The called dialog module contains errors (incorrect entry in table TDCT).

Runtime Error: CALL_DIALOG_WRONG_TDCT_MODE

Cause: No further paging area for parameter transfer available.

Runtime Error: CALL_DIALOG_NO_CONTAINER

Cause: The statement CALL DIALOG ... SCREEN ... PROGRAM ... is not supported.

Runtime Error: CALL_DIALOG_SCREEN/PROGRAM

[Former Member]

Hi Swapna,

The statement CALL DIALOG calls the dialog module whose name is contained in the character-like data object dialog.

The data object dialog must contain the name in uppercase.

If the dialog module specified in dialog is not found, an exception that cannot be handled is raised.

When calling the dialog module, the assigned ABAP program is loaded in a new internal session .

The session of the calling program is still available. In contrast to CALL TRANSACTION, the called program runs in the same SAP LUW as the calling program.

After loading the ABAP program, the event LOAD-OF-PROGRAM is triggered and the screen defined as the initial screen of the dialog module is called.

The dialog module is terminated when the corresponding screen sequence terminates upon reaching the next screen with screen number 0 or the program is exited using the statement

Instead of call dialog now we are using call transaction and session methods.

Reward points if useful.

Thanks & Regards,

AMK.

[Former Member]

Hi,

Using Dialog Modules

Dialog modules were the predecessors of function modules. They are now obsolete, and you should no longer create new ones.

Dialog modules are objects that, like transaction codes, are linked to a screen sequence in an ABAP program by means of an initial screen. When you call a dialog module, the system calls the corresponding ABAP program and the initial screen of the dialog module. Dialog modules can also have an interface. Before you can do this, you must have declared the parameters as global data in the ABAP program. Dialog modules are created and administered in the ABAP Workbench using a tool (Transaction SE35) similar to the Function Builder. You can assign more than one dialog module to the same ABAP program.

You call dialog modules using the CALL DIALOG statement:

CALL DIALOG <dialog>

[AND SKIP FIRST SCREEN]

[EXPORTING f1 FROM a1.... fn FROM an]

[IMPORTING f1 TO a1.... fn TO an]

[USING itab].

CALL DIALOG has the same syntax as CALL TRANSACTION. You can also pass values to the global data of the called program using the interface.

Although a dialog module occupies a new internal session, it runs in the same SAP LUW as the calling program. However, since they open a new session, they are less efficient than function modules in performance terms. Nevertheless, they are the only means of switching internal session without starting a new SAP LUW. You can only run an entire transaction within the SAP LUW of a calling program by linking the initial screen of the transaction with a dialog module.

If you want to run screen sequences and dialog modules in the SAP LUW of the calling program and as a transaction in their own SAP LUW, you must ensure that all database update tasks can be executed without compromising data integrity. The following special conditions apply:

Dialog modules inherit locks set by the calling program.

If the screen sequence is called as a dialog module, the system assumes that a lock for a particular object already exists. When you start the screen sequence as a transaction, you must set your own locks. To find out at runtime if a program is running as a called program, use the system variable SY-CALLD.

Dialog modules inherit update keys from the calling program.

When the screen sequence is running as a dialog module, the system partly ignores COMMIT and ROLLBACK WORK statements.

In the called program, the statements COMMIT WORK and ROLLBACK WORK lead to database commits or database rollbacks. However, procedures registered with CALL FUNCTION IN UPDATE TASK and PERFORM ON [COMMIT|ROLLBACK] are not executed till the corresponding statements in the calling program.

Update function modules called using the IN UPDATE TASK addition are not started if the screen sequence is running as a dialog module.

You must ensure that any function modules called with IN UPDATE TASK can be delayed until the next COMMIT WORK in the calling program.

PERFORM ON COMMIT routines are not executed in the dialog module.

You must ensure that any subroutines called using ON COMMIT can be delayed until the next COMMIT WORK in the calling program. Remember that the global data of the dialog module is destroyed along with the internal session when control returns to the calling program. Consequently, subroutines called using PERFORM ON COMMIT must not use this global data.

If you want to run the screen sequence as a transaction, you must ensure that the input parameters of the interface contain reasonable default values.

Reward points if helpful.

Thanks and regards.

Edited by: Ammavajjala Narayana on Mar 31, 2008 9:40 PM