|
Читайте также: |
START-OF-SELECTION.
SELECT carrid connid fldate seatsmax seatsocc FROM sflight
INTO CORRESPONDING FIELDS OF wa_flight
WHERE carrid = pa_car
AND connid IN so_con. wa_flight-percentage =
100 * wa_flight-seatsocc / wa_flight-seatsmax.
WRITE: / wa_flight-carrid, wa_flight-connid, wa_flight-fldate, wa_flight-seatsocc, wa_flight-seatsmax,
wa_flight-percentage, ’%’.
HIDE: wa_flight-carrid, wa_flight-connid, wa_flight-fldate. ENDSELECT.
IF sy-subrc NE 0.
WRITE ’Requested data not found!’. ENDIF.
CLEAR wa_flight.
AT LINE-SELECTION.
IF sy-lsind = 1.
WRITE: / wa_flight-carrid, wa_flight-connid, wa_flight-fldate. ULINE.
SKIP.
SELECT bookid customid custtype class order_date
Continued on next page
smoker cancelled loccuram loccurkey
FROM sbook INTO CORRESPONDING FIELDS OF wa_sbook
WHERE carrid = wa_flight-carrid AND connid = wa_flight-connid AND fldate = wa_flight-fldate.
WRITE: / wa_sbook-bookid color col_key, wa_sbook-customid,
wa_sbook-custtype, wa_sbook-class, wa_sbook-order_date, wa_sbook-smoker, wa_sbook-cancelled,
wa_sbook-loccuram CURRENCY wa_sbook-loccurkey,
wa_sbook-loccurkey.
ENDSELECT. ENDIF.
CLEAR wa_flight.
LessonSummary
You should now be able to:
• List the properties and benefits of selection screens
• Implement the options for restricting selections on the selection screen
• Implement the input and authorization check with an error dialog using the selection screen
Lesson:
248
Screen
Lesson Duration: 220 Minutes
Lesson Overview
In this lesson you will learn how to design and program simple screens with input/output fields and pushbuttons.
|
After completing this lesson, you will be able to:
• List attributes and benefits of screens
• Implement a simple screen with input and output fields as well as pushbuttons and call it from your program
• Explain and implement the program-internal processing for screen calls
|
This lesson represents the most difficult topic of the course and should be taught on an overview level only (not with details). At the end of this lesson, the participants should understand how a screen works, what is possible, and how to implement a simple screen. More details are taught in course BC410.
Business Example
You are to develop a program with screen output of data that needs to be changed. Furthermore, the corresponding functions of your program are to be accessible
via pushbuttons.
The Screen
|
Figure 153: Features of Screens
A screen not only consists of its layout with input/output fields, pushbuttons and other screen elements but also a processing logic (source code excerpts that are processed as the pre-/postprocessing of the screen display).
The fact that the ABAP Dictionary is integrated in the system means that automatic consistency checks for screen input fields are provided. These checks include
type checks, foreign key checks, and fixed value checks. All of these checks are automatically supplied with information from the ABAP Dictionary.
Checks like the ones above can be complemented by other program-specific checks. There are techniques available for screens that allow you to control the order in which checks are performed and, if errors occur, to make the fields input-ready again, where appropriate.
The layout can be designed very flexibly, with input fields, output fields, radio buttons, check fields and, most importantly, pushbuttons with which the corresponding functions of the program can be executed.
Screens offer the same formatting options as lists and selection screens: Fixed point numbers and dates are formatted according to the settings in the user master record; the time is set to hh:mm:ss; sums of money are formatted according to the currency field, and physical sizes (lengths, weights,...) are formatted according
to the content of a unit field.
|
You start a screen sequence by calling up the first screen from the processing block of your program. After a screen is processed, the statically or dynamically defined screen sequence is processed. The formal next screen 0 sends processing back to the point where the screen was called.
|
Figure 155: Components of a Screen
Each screen has the following components:
Properties (attributes)
Properties contain, for example, a four-digit number as the screen name, a short text, information on the screen type (for example, Normal for full screen size) and also specify the default next screen.
Layout
You can place input/output fields, texts, pushbuttons, and other elements on your screen. Such elements are called screen elements.
Element list
Lists all screen elements including their attributes such as position, size, data type, and so on.
Flow logic
The flow logic of a screen consists of the PBO (Process Before Output) and the PAI (Process After Input). PBO contains references to processing blocks (PBO modules) that are processed in preparation for the screen display (for example, data selection) before the screen is sent. PAI contains references
to processing blocks (PAI modules) that are processed as a reaction to user input and actions (for example, save data).
|
Figure 156: Graphic Layout Editor
You can use the toolbar of the Graphical Screen Painter to design the structure of the screen. You also have the following maintenance functions using the three pushbuttons depicted in the above graphic:
Maintain element attributes
In a dialog box, all attributes for the selected screen element are displayed for maintenance.
Get Dictionary or program fields
You can use a dialog box to create screen fields with reference to fields from
Dictionary structures or fields defined within the program.
Show element list
Shows all available screen elements including their attributes for maintenance
|
In the following sections, we will develop a program step-by-step. This program will enable users to change the master data of the flight schedule.
Flight connections are shown in the basic list. When a user selects a flight connection, it takes him to a screen where the detailed data for the selected row is displayed (some of the details are input-ready for maintenance).
Choosing Back takes the user back to the basic list without changing any data.
If the user chooses Save, then all the data entered will be changed in the database and the user is taken back to the basic list with an appropriate message. There is a function module available for database changes, which we will discuss/implement in a later unit.
|
From now on, the best thing to do is to complete the corresponding exercise at the end of each section. The database change is only to be prepared in this unit. You will implement this later by calling a function module. The program SAPBC400UDD_LIST from package BC400 provides a suitable template for the demo.
Create and Call a Screen
|
Figure 158: Realization Level 1: Create and Call a Screen
The first step is to create a screen, specify its layout, and define its field attributes. The fields Airline Carrier, Flight Number, Departure Airport, and Destination Airport are to appear as output fields. The fields Flight Duration and Departure Time are to be made available as input-ready fields.
Users should be able to call the screen by double-clicking a line within the basic list and should be able to return to the basic list by choosing the appropriate function on the screen.
|
There are several ways to create a screen:
By means of forward navigation from the ABAP Editor
In the ABAP Editor, double-click the screen number to create a screen (see above graphic). The system automatically opens the Screen Painter for maintaining the new screen.
Using the Object Navigator
You can create a new program object (screen) for your program from the object list in the navigation area using the context menu for your program.
When you create a screen, the system will first ask you to enter screen attributes. Enter a short description of the screen, select screen type Normal, and enter
the number of the subsequent screen.
If you enter 0 for the subsequent screen, the system first processes the screen completely and then returns to processing at the point where the screen was called.
Caution: As zero is the initial value of the field; it is hidden when the screen attributes are displayed.
In this application example, the screen the user creates is supposed to be called from within the basic list. This means that CALL SCREEN... must belong to the event block AT LINE-SELECTION.
|
Fields)
You have two options for implementing the assignment of field attributes when you create screen fields:
Get from Dictionary:
When you create a screen field, you can copy the type as well as the field attributes of a Dictionary field. This makes all the information about
the object available to you, including semantic information about the corresponding data element and foreign key dependencies. The field name is also copied from the ABAP Dictionary.
Get from program:
You can copy the field attributes of a program-internal data object for a screen field. To do so, a generated version of the program must be available (is automatically generated at the time of activation). The name of the data object is used as the field name.
The Graphical Screen Painter offers you comfortable options for defining further screen elements such as texts, frames, radio buttons, checkboxes, and so on. First, click on the required screen element in the tool bar to select it and then position it in the screen maintenance area.
You can delete screen elements by selecting them with the mouse and then choosing Delete.
You can move screen elements by holding down the left mouse button and dragging them to a new position.
|
Double-click a screen element to maintain its attributes. Its attributes are displayed in an additional window for maintenance. (Instead of double-clicking you can also select the element and then choose Attributes.)
To make input mandatory, assign the attribute Required to a screen field. At runtime, the field will be marked accordingly if it is blank. If the user does not fill out the field, then an error dialog will follow any user action. After this dialog the input fields are ready for input again.
Data Transports Between the Program and the Screen
|
Figure 162: Realization Level 2: Displaying Data on the Screen
After the first realization level, a screen is shown when a row is selected from the basic list. But all screen fields are set to their initial values. In the second level, the data transport from the program to the screen should be programmed so that appropriate values appear on the screen.
|
The TABLES statement is used to define a structure variable of the same type and name with reference to the specified Dictionary structure (for example, a transparent table) within the program. This structure variable then serves as the interface between the program and the screen.
If the screen fields and the TABLES statement refer to the same structured type, then the data of their fields is automatically exchanged on the basis of the fields having the same names. After PBO, from the TABLES structure to the screen fields, and before PAI in the other direction.
It is common to create a Dictionary structure explicitly for the data exchange. This structure contains fields with the types of fields from various database tables. On the screen, fields are defined with a reference to this structure and an interface structure is implemented within the program using the corresponding
TABLES statement. This way, you still have a clear interface structure for the data exchange between program and screen, in spite of having fields from different tables. For our Flugdatenmodell, for example, a structure (SDYN_CONN) was created with fields from SCARR, SPFLI, and SFLIGHT as well as a structure (SDYN_BOOK) with fields from SBOOK and SCUSTOM.
|
After processing the events of PBO and immediately before sending a screen to the presentation server, the field contents of the TABLES structure within the program are automatically copied to the screen fields with the same names. The moment of this automatic data transport makes sense as the data for the screen display in the TABLES structure is often prepared in PBO.
|
For user actions on the screen, the contents of the screen fields are transported into TABLES structure fields with the same names before the PAI event is processed. The time of this automatic data transport makes sense, as the user entries are supposed to be processed further in PAI and thus have to be available in the program at that time.
|
Our application program uses the following automatic data transports:
If data objects and their values were stored in the HIDE area when the basic list was created, the data belonging to the selected line will be written back into the corresponding data objects. For each basic list row, we will put the key values of the corresponding flight connection in the HIDE area, so that these are available for further processing when the row is selected.
You must copy the data to be displayed on the screen to a TABLES structure by means of appropriate statements. From there, they are automatically transported to the screen fields after the PBO of the screen. In our example of Dictionary structure SDYN_CONN, we will define SDYN_CONN fields on the screen and the SDYN_CONN TABLES structure in the program.
For user actions on the screen, the user entries are automatically transported to the program-internal TABLES structure SDYN_CONN for further processing. This happens even before the PAI is processed.
|
The above table shows the realization of the fields on the basic list and the screen.
|
Figure 168: Syntax of the Example Program
You can implement the reading of the data for the screen display at any time before sending the screen to the presentation server. There are several ways of doing this:
• You start by reading the data to be displayed on the screen before retrieving the basic list from the database. You then place this data and the key values in the HIDE area. For AT LINE-SELECTION, all you have to do is copy the data to the TABLES structure so that it is transported to the screen.
Disadvantage: You might read a lot of data from the database that is of no interest to the user. If the detailed data in the database has changed between creating the basic list and displaying the screen, the system will display obsolete data.
• As illustrated in the above graphic - you read the selected flight connection from the database using SELECT SINGLE directly before calling the screen.
Disadvantage: The system sends a query to the database every time the user double-clicks the list.
Advantages: You only read required data. Apart from that, the data is always up to date.
Hint: Please note that for data changes you must make sure that the data
is current and you also have to implement a lock to prevent change access to the data by third parties. You can find out more about data changes in course BC414.
To display data on the screen, the TABLES structure must be filled with read data before the screen is sent to the presentation server (MOVE-CORRESPONDING statement).
Pushbuttons
|
Figure 169: Realization Level 3: Implementing Pushbuttons
In the third level of our example, different pushbuttons and the program are to be implemented in such a way that the appropriate processing for the user action
is executed:
• By choosing the Back pushbutton, the user returns to the basic list without writing any changes to the database table. The following message appears in the status bar of the basic list: “You exited the screen without saving”.
• By choosing Save the changes are made in the database and the user returns to the basic list with a corresponding message in the status bar. (The database update is not implemented in the program until later. However, the pushbutton is already prepared here.)
• By choosing Enter the screen is re-displayed. This section deals with the following:
• Flow logic of a screen in PBO and PAI event blocks
• PBO and PAI modules as processing blocks for the corresponding events
• Implementing pushbuttons and evaluating user actions
|
If the user chooses a pushbutton, the runtime system copies the assigned function code to a special screen field (of the OK type). This screen field is typically called the ok_code.
The content of this special screen field is automatically transported if there is a data object of the same name within the program. Following that, PAI processing is triggered, in which you find out about the user action via the function code transferred to the program and carry out appropriate processing.
The following sections tell you how to define pushbuttons that use the special screen field of the 'ok' type, declare a data object of the same name within the program and react to the respective user action.
|
The above graphic illustrates how you define pushbuttons in the Graphical Screen Painter. You have to assign a name and function code to each pushbutton. You can do so using the maintenance of the field attributes.
|
Figure 172: Implementing the Function Code Transport
The special screen field with which the respective function code is transported to the program, is called the command field and is available on the screen by default. In order to be able to use it, you have to give it a name. In most cases, OK_CODE is used as the name.
You declare the program-internal data object with the same name by assigning the type to the system field sy-ucomm (see above graphic).
|
Figure 173: Runtime Architecture of the Screen Flow Control
The CALL SCREEN statement is used to trigger screen processing. This includes the following steps (that are executed automatically):
PBO processing
In preparation for the screen display, the PBO modules listed in the PBO
block are processed successively.
Field transport from the program to the screen
After PBO processing, the contents of the fields of the TABLES structure are transported to the screen fields with the same names.
Screen display
The screen that has been assigned values is sent to the presentation server
(SAPGui) and shown to the user.
Field transport from the screen to the program
Each user action on the screen triggers the transport of the field contents to the fields with the same names in the TABLES structure.
PAI processing
As a reaction to the user action, the modules listed in PAI are processed successively.
Modules are source code blocks without interface. They are enclosed by the ABAP statements MODULE and ENDMODULE. For each subfunction in PBO or PAI, a corresponding module should be implemented.
Caution: The flow logic of the screen (PBO/PAI) only contains references to modules, which are implemented in the program and consist of ABAP statements. ABAP source code may not be stored directly in the flow logic.
|
Figure 174: Evaluating the Function Code at the PAI Event
The above graphic shows the program's reaction to the user action. The corresponding function code that was transferred to the OK_CODE field immediately before PAI processing is evaluated.
Usually, the module with the main processing in PAI is called
USER_COMMAND_nnnn, whereby nnnn represents the screen number.
Hint: In a module, you can access all global data objects of the program.
Variables defined within the module are always global.
|
There are two ways to create a module:
Using forward navigation from the flow logic
Starting from the flow logic of your screen, you can double-click the module reference to create the corresponding module (see above graphic).
Using the navigation area of the Object Navigator
You can also create a module from the object list of your program. To do so, use the context menu of the program. In this case, note that you have to include a corresponding reference to the newly created module in the flow logic of your screen.
A module can be called from the flow logic of several screens (reusability).
Please note that modules starting with MODULE... OUTPUT are PBO modules and can only be called by the PBO of a screen. Accordingly, PAI modules starting with MODULE... INPUT can only be called by PAI.
|
If you enter the screen attribute “next screen = 0 ”, the system first processes your screen completely and then returns to processing at the point where the screen call is set.
|
Figure 177: Next Screen“Ssame Screen” (Effect)
If a screen is assigned its own screen number as the next screen, then it is processed again after it is closed.
|
You can use the ABAP statement SET SCREEN from a module (typically a PAI module) to dynamically overwrite the default next screen specified in the screen attributes (see above graphic). This option can be used for implementing the following SAP standard: When you choose Enter you return to the same screen; only certain pushbuttons take you to other screens. For your screen, enter its
own screen number as the next screen (default next screen) and branch to other screens (using the SET SCREENcommand) from PAI only if certain pushbuttons are pressed. (By default, the Enter button does not insert a function code into the command field of the screen). Hence, the initial value of the field (Space) is transported to the program as the function code.
Note: If the system processes the same screen again, it also runs through all the PBO modules again. If you decide to fill the TABLES structure in a PBO module, you must make sure that data changes made by the user are not overwritten on the screen if the module gets called twice.
|
For this example, two pushbuttons are to be handled:
• For Back (function code BACK) the next screen is automatically set to zero to return to the call point of the screen. In our case this means the return to the basic list, as a screen was sent in the AT LINE-SELECTION block, but no details list was generated. On the next screen message 057 appears in the status bar as it is sent with type 'S'.
• For Save (function code SAVE) the program reacts in the same way as for Back but with a different message in the basic list. We will extend the program to include changing data records in the database in a later lesson.
|
In the section below, we need to analyze a very particular scenario, to point out the need for a further program step.
When the user selects a basic list row, he is sent a screen for changing the corresponding data. After changing the data on the screen and choosing Save the user is returned to the basic list after the changes have been made in the database. If the user now selects a new record, then the screen is not processed again when he chooses the Enter button, instead a save is made in the database and he is returned to the basic list! Why?
When the user saves the data, function code 'SAVE' is transported to the ok_code
variable within the program. When the screen is called the second time (after the row has been selected again) the PBO field contents are transferred to the screen. As the ok_code variable still contains 'SAVE', this is transported to the command field of the screen. When you press the Enter button, which by default does not enter a function code in the command field but only triggers the field transport from the screen to the program including PAI processing, the unintended function code 'SAVE', which is still in the command field, is transferred to the program-internal ok_code variable and evaluated in PAI:
|
To eliminate the above-described, undesirable response of our program we have to make sure that no unintentional function codes are transferred to the command field of the screen. There are two basic options:
• You initialize the program-internal ok_code variable in a PBO module, before the field transport to the screen.
• You use an auxiliary field in PAI processing, copy the value of the ok_code
variable into this field, and initialize ok_code at this point already.
275 Exercise 14: Creating and Calling a Screen
Exercise Duration: 40 Minutes
Exercise Objectives
After completing this exercise, you will be able to:
• Create screens
• Call existing screens from the program
Business Example
The program SAPBC400UDT_DYNPRO enables you to display all bookings made by one travel agency as a list. It should now be enhanced as follows:
When you double-click a line item, a screen is called up, which contains the display and input fields for the attributed of the choosing booking. After each user action on the screen, the program returns to the basic list.
System Data
System: Will be assigned Client: Will be assigned User ID: Will be assigned Password: Will be assigned
Set up instructions: No special instructions when using a standard training
system
Task 1:
Create and call a screen
1. Copy the template SAPBC400UDT_DYNPRO to your new program
ZBC400_##_DYNPRO_1.
2. Get to know the program. Test the program using the travel agency number
1## where ## is your group number.
3. Change the program so that when the user selects a line on the basic list (by double-clicking or using F2), it calls a screen. Create this screen (screen number 100) using forward navigation.
4. When specifying the attributes, assign screen number 0 as the number of the next screen, so that after any user action on screen 100, the user returns to the basic list.
Continued on next page
Task 2:
Place and maintain screen elements
1. Create input/output fields for booking data on the screen. For assigning field types, use the ABAP Dictionary structure SDYN_BOOK. The following fields should be taken over here:
The booking table key fields CARRID, CONNID, FLDATE, and BOOKID should be copied with their field labels; the same goes for the fields CUSTOMID (customer number) and LOCCURAM (amount).
The field LOCCURKEY (currency key) is to be copied without a field label and appear to the right of the amount field.
2. Maintain the screen element attributes:
The fields CARRID, CONNID, FLDATE, BOOKID, and CUSTOMID
should appear as output fields (attribute Output Field).
The LOCCURAM is to display the corresponding value from the program
as changeable (attributes Input Field + Output Field).
The currency key LOCCURKEY is to be displayed as a non-changeable display field without “field box” (attribute Output Only).
Solution 14: Creating and Calling a Screen
Task 1:
Create and call a screen
1. Copy the template SAPBC400UDT_DYNPRO to your new program
ZBC400_##_DYNPRO_1.
a) Carry out this step as usual.
2. Get to know the program. Test the program using the travel agency number
1## where ## is your group number. a) Carry out this step as usual.
3. Change the program so that when the user selects a line on the basic list (by double-clicking or using F2), it calls a screen. Create this screen (screen number 100) using forward navigation.
a) See the source code excerpt in the model solution.
b) Create a screen using forward navigation: Double-click on 100 from statement CALL SCREEN 100.
4. When specifying the attributes, assign screen number 0 as the number of the next screen, so that after any user action on screen 100, the user returns to the basic list.
a) Maintain the screen attributes as specified.
Task 2:
Place and maintain screen elements
1. Create input/output fields for booking data on the screen. For assigning field types, use the ABAP Dictionary structure SDYN_BOOK. The following fields should be taken over here:
The booking table key fields CARRID, CONNID, FLDATE, and BOOKID should be copied with their field labels; the same goes for the fields CUSTOMID (customer number) and LOCCURAM (amount).
Continued on next page
The field LOCCURKEY (currency key) is to be copied without a field label and appear to the right of the amount field.
a) Navigate to the Graphic Layout Editor. b) Use the Dict/Program fields key
c) Enter SDYN_BOOK
d) Choose the Get from Dictionary pushbutton e) Select the required fields
f) Choose the no text option for the “LOCCURKEY” field
g) Choose Enter to confirm, and drag these fields to the screen
2. Maintain the screen element attributes:
The fields CARRID, CONNID, FLDATE, BOOKID, and CUSTOMID
should appear as output fields (attribute Output Field).
The LOCCURAM is to display the corresponding value from the program
as changeable (attributes Input Field + Output Field).
Continued on next page
The currency key LOCCURKEY is to be displayed as a non-changeable display field without “field box” (attribute Output Only).
a) To navigate to the field attributes you can either double-click the screen element or use the Element List pushbutton.
Result
Source code excerpt: SAPBC400UDS_DYNPRO_1
REPORT sapbc400uds_dynpro_1.
CONSTANTS actvt_display TYPE activ_auth VALUE ’03’. PARAMETERS pa_anum TYPE sbook-agencynum.
* workarea for SELECT
DATA wa_sbook TYPE sbook.
START-OF-SELECTION.
SELECT carrid connid fldate bookid
FROM sbook
INTO CORRESPONDING FIELDS OF wa_sbook
WHERE agencynum = pa_anum.
AUTHORITY-CHECK OBJECT ’S_CARRID’
ID ’CARRID’ FIELD wa_sbook-carrid
ID ’ACTVT’ FIELD actvt_display.
IF sy-subrc = 0.
WRITE: / wa_sbook-carrid COLOR col_key, wa_sbook-connid COLOR col_key, wa_sbook-fldate COLOR col_key,
wa_sbook-bookid COLOR col_key,
ENDIF. ENDSELECT.
Дата добавления: 2015-11-16; просмотров: 120 | Нарушение авторских прав
| <== предыдущая страница | | | следующая страница ==> |
| SELECT-OPTIONSname FORdata_object. | | | CALL SCREEN 100. |
