topic Re: Screen Exits in Application Development and Automation Discussions

Screen Exits

Former Member — Fri, 10 Aug 2007 12:50:29 GMT

Can any one give User exits for Screen Exits and Field Exits?

i mean like PBAS0001 is a User exit for Function Exits.

Re: Screen Exits

Former Member — Fri, 10 Aug 2007 12:53:09 GMT

Hi,

Here is the code to find the Screen exits for a transaction code

REPORT YSMOD2 .

TABLES: MODSAP, MODACT, TSTC.

PARAMETERS: INPUT1 LIKE TSTC-TCODE DEFAULT ' ',

INPUT2 LIKE MODSAP-TYP DEFAULT ' '.

DATA: SEARCH1(6),

SEARCH2(3),

SEARCH3 LIKE MODSAP-MEMBER.

DATA : FIRST_ROW VALUE 'Y'.

CONCATENATE: '%' INPUT1 '%' INTO SEARCH1,

'%' INPUT2 INTO SEARCH2.

SELECT * FROM TSTC WHERE TCODE LIKE SEARCH1.

FIRST_ROW = 'Y'.

CHECK TSTC-PGMNA NE SPACE.

CONCATENATE '%' TSTC-PGMNA '%' INTO SEARCH3.

SELECT * FROM MODSAP WHERE TYP LIKE SEARCH2

AND MEMBER LIKE SEARCH3.

SELECT SINGLE * FROM MODACT WHERE MEMBER = MODSAP-NAME.

IF FIRST_ROW EQ 'Y'.

WRITE: /0 TSTC-TCODE, 6 TSTC-PGMNA, 16 MODSAP-NAME, 32 MODSAP-TYP,

45 MODSAP-MEMBER, 70 MODACT-NAME.

FIRST_ROW = 'N'.

ELSE.

WRITE: /16 MODSAP-NAME, 32 MODSAP-TYP, 45 MODSAP-MEMBER, 70 MODACT-NAME.

ENDIF.

CLEAR : MODSAP, MODACT.

ENDSELECT.

IF SY-SUBRC NE 0.

WRITE : /0 TSTC-TCODE, 6 TSTC-PGMNA, 30 'No exits found'.

ENDIF.

CLEAR TSTC.

ENDSELECT.

END-OF-SELECTION.

CLEAR: SEARCH1, SEARCH2, SEARCH3.

Regards

Sudheer

Re: Screen Exits

Former Member — Fri, 10 Aug 2007 13:48:26 GMT

You havnt clearly specified what you want to search for. Please refer to the code below to find the applicable exit for ur transaction....

Find the available exits with the following program:::

&----

*& Report ZFINDUSEREXIT

&----

report zfinduserexit.

tables : tstc, tadir, modsapt, modact, trdir, tfdir, enlfdir.

tables : tstct.

data : jtab like tadir occurs 0 with header line.

data : field1(30).

data : v_devclass like tadir-devclass.

parameters : p_tcode like tstc-tcode obligatory.

select single * from tstc where tcode eq p_tcode.

if sy-subrc eq 0.

select single * from tadir where pgmid = 'R3TR'

and object = 'PROG'

and obj_name = tstc-pgmna.

move : tadir-devclass to v_devclass.

if sy-subrc ne 0.

select single * from trdir where name = tstc-pgmna.

if trdir-subc eq 'F'.

select single * from tfdir where pname = tstc-pgmna.

select single * from enlfdir where funcname =

tfdir-funcname.

select single * from tadir where pgmid = 'R3TR'

and object = 'FUGR'

and obj_name eq enlfdir-area.

move : tadir-devclass to v_devclass.

endif.

select * from tadir into table jtab

where pgmid = 'R3TR'

and object = 'SMOD'

and devclass = v_devclass.

select single * from tstct where sprsl eq sy-langu and

tcode eq p_tcode.

format color col_positive intensified off.

write:/(19) 'Transaction Code - ',

20(20) p_tcode,

45(50) tstct-ttext.

skip.

if not jtab[] is initial.

write:/(95) sy-uline.

format color col_heading intensified on.

write:/1 sy-vline,

2 'Exit Name',

21 sy-vline ,

22 'Description',

95 sy-vline.

write:/(95) sy-uline.

loop at jtab.

select single * from modsapt

where sprsl = sy-langu and

name = jtab-obj_name.

format color col_normal intensified off.

write:/1 sy-vline,

2 jtab-obj_name hotspot on,

21 sy-vline ,

22 modsapt-modtext,

95 sy-vline.

endloop.

write:/(95) sy-uline.

describe table jtab.

skip.

format color col_total intensified on.

write:/ 'No of Exits:' , sy-tfill.

else.

format color col_negative intensified on.

write:/(95) 'No User Exit exists'.

endif.

else.

format color col_negative intensified on.

write:/(95) 'Transaction Code Does Not Exist'.

endif.

at line-selection.

get cursor field field1.

check field1(4) eq 'JTAB'.

set parameter id 'MON' field sy-lisel+1(10).

hope it helps

reward if helpful

regards

Ankit

Re: Screen Exits

Former Member — Fri, 10 Aug 2007 13:58:46 GMT

Hi,

they are available on 4.7

Please take a look OSS Notes: 29377

Note

Field exits are frozen on the 4.6C maintenance level and are not further developed. This means that the existing functionality is kept with all restrictions (see also the last item below). Existing exits can be further used and are called at runtime as usual.

Existing exits can be maintained using program RSMODPRF (run the

program using transaction SE38). Activation of the field exits and

assignment of the dynpros can also be carried out using program

RSMODPRF. For this purpose, the program must be started without

parameters (input fields remain blank).

If required, new field exits can be created using program

RSMODPRF (see the program documentation).

Solution

1. Field exit was created with CMOD, but is not processed when calling the screen.

Since the field exit is not processed until PAI, an action must be triggered on the screen (Return, Save, ...).

Set profile parameter abap/fieldexit to YES and restart the system.

After activating the function module FIELD_EXIT... and the field exit, leave the transaction on whose screen the field exit is to be executed. The screen is not generated until the transaction is started.

Do not work on different application servers since there may be some delay before the field exit is activated.

The profile parameter must be set on all or none of the application servers.

If the field exit is to only be active on specific screens, check whether you chose the correct program and the correct screen number (take care with subscreens).

Generate the screen on which the exit should be active using SE51. It is possible that it was not correctly generated. If you want to be sure that all screens that use the data element are regenerated, you can transfer Report rsmodfdg from the correction instructions and start it with SE38. The Report uses the affected data element as the input parameter and regenerates all screens that use the data element.

Using SE51 -> Field list, check that the screen field does have a reference to a data element. In the name of the field exit, use the name of the data element and not the field name.

After transport, field exits are marked as active but will not be processed. Tip: First try deactivating the field exit once more and then activate it again.

2. How is performance affected by setting abap/fieldexit?

If a screen is generated and the profile parameter is set, a check is run on 2 tables (TDDIR, TDDIRS) to see whether a field exit must be generated for the respective field. In practice, the screen load is not generated until the screen is selected after an update. The user should not notice any difference because screen generation is very fast.

3. Can you read the contents of other screen fields in the field exit?

In principle, every field exit can store its value in the global variables of the function group (TOP) and hence make them available to other field exits. Note here that field exits are always called, not only if an entry is made in the field or if the field is empty. In addition, it is not possible to make any assumptions about the order in which the field exits will be called in the future.

4. How does the field exit behave on step loop fields ?

After the user has entered data, the field exit is called in PAI as often as there are visible fields in the step loop. The system variable SY-STEPL is incremented each time. If a new value is assigned to the field, it is displayed in the module between LOOP and ENDLOOP. This module is also called once for each visible step loop line.

5. Can field exits be debugged ?

No. Field exits must be tested separately in the ABAP/4 Development Workbench. For errors which only occur in the screen environment, it is helpful to write interesting variables to the file system using TRANSFER... . These can then be analysed there.

6. What can you do if the field contents are no longer transported to ABAP/4?

Check whether a value is assigned to the field OUTPUT.

7. When is the field exit called if a conversion exit is attached to the data element?

The field exit is called after the conversion exit. This means that the INPUT field receives the data in the same format as the ABAP/4 program receives it.

8. Although a global field exit is inactive, a function module is called which does not exist (for example FIELD_EXIT_PROGRAMM_@). This can lead to an ABAP dump error when function module FIELD_EXIT_<data element name> is called.

This is an error in the kernel which no longer occurs as of Release 3.0C. As a temporary measure, it is useful to assign a program and a screen which do not exist to the field exit and then activate the field exit.

Due to performance reasons, the active/inactive indicator is stored in the screenload. This can cause inconsistencies between Source and Load. Generate the affected screen with se51. If you want to be sure that all screens that use the data element are regenerated, you can transfer Report rsmodfdg from the correction instructions and start it with se38. The Report uses the affected data element as the input parameter and regenerates all screens that use the data element.

9. Field exit is not visible in CMOD, although created.

If you want to create a field exit for a data element, a function module is proposed with the name FIELD_EXIT_<data_element>. This function module must exist for the field exit to work. If you do not create this function module, but do create one with a suffix, the data element is not displayed in CMOD.

10. Field exit is not executed although it is active.

Fields which do not have the 'Input field' attribute usually do not trigger a field exit. The field exit is designed to allow an extended input check. It is therefore only called for input fields - even if they are not ready for input at runtime of the application by LOOP AT SCREEN.

This rule does not apply, however, if the field is located within a steploop. Here the field will be always activated, even if it is invisible.

Field exits can only be executed for fields that are directly related to the dictionary. If the relation is indirect, i.e. via an ABAP declaration (<fieldname> LIKE <dictionary element>), no field exit can be executed.

11. Field exits do not work on selection screens.

Results from the previous item since ABAP-internal fields and never the original Dictionary fields are used on selection screens.

12. Field exists do not work on check buttons.

Field exits are only intended for input fields. As check buttons count as graphical elements, you cannot install field exits on them.

13. How can all screens that use a data element be generated?

If you want to be sure that all screens that use a specific data element are regenerated, you can transfer Report rsmodfdg from the correction instructions into a customer report (e.g. zsmodfdg). The Report regenerates all screens. In this way, you can ensure that active field exits refer to screens and that inactive exits cannot be called on any screen. The Report uses the affected data element as the input parameter. The affected data element is in the name of the exit: FIELD_EXIT_<data element name>.

14. Restriction of usage

Field exit technology was developed for input fields on dynpros and cannot be used for other/new dynpro elements. This means that this technology does not offer support for the new ScreenPainter elements such as graphical elements (e.g. checkbuttons, radiobuttons, dropdown listboxes), controls (except for table controls which are supported like a step loop), or selection screens

check the below link, may be helpful for you

http://www.sap-img.com/abap/field-exits-smod-cmod-questions-and-answers.htm

regards

Re: Screen Exits

Former Member — Fri, 24 Aug 2007 05:25:08 GMT

Screen exits are exits that allow you to use a reserved part of the screen (A subscreen) to display or

input data.

It is determined be SAP where the sub screen will be displayed.

The syntax is: CALL CUSTOMER-SUBSCREEN

The screen exit is not processed untill the corresponding subscreen has been created in an

enhancement project, and the project has been activated.

Note:

Function codes are only processed in the main screens flow logic

You are not allowed to enter a name for the subscreens command field

You are not allowed to define GUI stauses

You are not allowed to enter a value for Next screen

The global data of the program is not available for the subscreen. Data for the subscreen is provided

by function modules. These function modules belongs to the same function group as the subscreen

Subscreens are edited with transaction CMOD. When you activate a project containg subscreens,

the calling screen is regenerated and the subscreen is displayed next time you display the calling

screen

The developer must create the subscreen and the corresponding PBO and PAI modules

How to identify screen exits

Look after CALL CUSTOMER-SUBSCREEN in the screenprogram of the screen you want to modify.

Use transaction CMOD menu Utillities -> SAP enhancements to search for screen exits

Runthe report in the chapter Report for finding User Exit. Search for the words "screen exit" in the

report

An example of a screen exit can be found in an IDES system, transaction BC425_01 screen 200. You

can also take a look on function group WLF2 screen 0206.

reward if usefull