Oracle forms les03

Editor's Notes

• #3: Introduction Overview This lesson provides you with an overview of Forms Builder, including a high-level description of its components and object hierarchy. Using this knowledge, you can plan and implement the structure of your form applications.
• #4: Forms Builder Key Features Forms Builder is a major component of Oracle Forms Developer. You can use Forms Builder to quickly develop form-based applications for presenting and manipulating data in a variety of ways. Users of Forms Builder applications can: Insert, update, delete, and query data by using a variety of interface items Present data by using text, image, and custom controls, including JavaBeans and Pluggable Java Components Control forms across several windows and database transactions Access comprehensive facilities by using integrated menus Send data directly to Oracle Reports As the designer of Forms Builder applications, you can: Design forms that use a number of data sources, including Oracle databases Build applications quickly and easily by using powerful GUI development tools Design applications for Internet deployment Copy and move objects and their properties easily between applications Use design features such as wizards, the Layout Editor, Object Navigator, and PL/SQL Editor
• #5: Forms Builder Components: Object Navigator The interface components of the Forms Builder tool help to provide the flexibility and productivity of the Oracle Forms Developer development environment. The Object Navigator is a hierarchical browsing and editing interface. You can use the Object Navigator to locate and manipulate application objects quickly and easily. Features include: A hierarchy represented by indentation and expandable nodes (Top-level nodes show module types, database objects, and built-in packages. All other nodes and the objects they contain are indented to indicate that they belong to these higher-level nodes.) Find field and icons, enabling forward and backward searches for any level of node or for an individual item in a node Icons in the vertical toolbar replicating common Edit and View menu functions An icon next to each object to indicate the object type
• #6: Forms Builder Components: Property Palette All objects in a module, including the module itself, have properties that you can see and modify in the Property Palette. Features include: Copy and reuse properties from another object Find field and icons, similar to Object Navigator
• #7: Forms Builder Components: Layout Editor The Layout Editor (or Layout Model) is a graphical design facility for creating and arranging interface items and graphical objects in your application. You can use the Tool palette and the toolbar available in the Layout Editor to design the style, color, size, and arrangement of visual objects in the application. The layout can include graphical objects and images.
• #8: Forms Builder Components: PL/SQL Editor The PL/SQL Editor enables you to incorporate PL/SQL code objects into your form. Code objects in Forms Developer include event triggers, subprograms (functions and procedures), menu item commands, menu startup code, and packages. You enter and compile code in the PL/SQL Editor. You will learn more about the PL/SQL Editor in later lessons when you use it to code triggers in Forms Builder.
• #9: Getting Started in the Forms Builder Interface Starting Forms Builder To start Forms Builder, invoke it from the Windows Start menu: Programs > Oracle Developer Suite – iDS10g > Forms Developer > Forms Builder. When you invoke Forms Builder, you first see a Welcome dialog box. If you click Cancel to dismiss the dialog box, you see the Object Navigator and an empty new module. If you build applications that access database objects, you must connect to a database account from the Forms Builder. Connect to a database if you need to: Compile code that contains SQL Access database objects in the Object Navigator Create Oracle Forms Developer objects that are based on database objects
• #10: Getting Started in the Forms Builder Interface (continued) How to Connect to Oracle 1.Select File > Connect from the menu, or click the Connect icon in the toolbar. 2.Enter the database user and password in the Connect dialog box. If not connecting to the default database, also provide the necessary connect string or database alias.Note: Oracle Forms Developer automatically displays the Connect dialog box if you try to perform a task that requires connection.
• #11: Navigating the Forms Builder Main Menu The Forms Builder main menu contains options to enable you to create, modify, and manage your form modules. Common Menu Features The following table describes some common features in GUI menus: Native GUI Interface The menu shown in the slide depicts the Windows NT environment. However, menus appear with the same look and feel of your native GUI interface. For example, in Motif, the Windows Print Dialog options appear as submenus of the Font menu.
• #12: Navigating the Forms Builder Main Menu (continued) Forms Builder Main Menu
• #13: Forms Builder Components Form modules make up the main “body” of an Oracle Forms Developer application. They can consist of many types of objects, some of which are visible to the user at run time. The three major objects in a form are: Items: These are interface objects that present data values to the user or enable the user to interact with the form, depending upon the item type. There are several different types of items. Items are logically grouped into blocks and visibly arranged on canvases. Blocks: A block is the intermediate building unit for forms. Each form consists of one or more blocks. A block is the logical owner of items, and each item in a form belongs to a block. Items in one block are logically related; for example, they may correspond to columns in the same database table or may need to be part of the same navigation cycle.Blocks therefore provide a mechanism for grouping related items into a functional unit for storing, displaying, and manipulating records.
• #14: Forms Builder Components (continued) Canvases: A canvas is a “surface” where visual objects, such as graphics and items, are arranged. A form module can have several canvases (like the pages of a paper form). A canvas can display items from one or more blocks. To see a canvas and its items, you must display the canvas in a window. By default, all canvases in a form appear in the same window (which could mean you see only one canvas at a time), but you can assign separate windows for each canvas so that several canvases can be viewed at once. Note: Items in one block do not need to be physically grouped. They can span many canvases (and windows).
• #15: Navigation in a Form Module When you run a form, you principally navigate by way of items and blocks, not by canvases. Each item has a sequenced position within its block, and each block has a sequenced position in the form. When a user requests to move to the next item in a block, focus will be set on the next item in sequence, wherever that may be. If the next item is on a different canvas, Oracle Forms Developer displays that canvas automatically. Similarly, users can request to move to the next block (or previous block). If the first item in this block resides on another canvas, then that canvas is displayed automatically. Of course, if you can already see the item that you want to move to, then you may click on it directly with the mouse. You can also program mechanisms into the application to enable navigation in other ways.
• #16: Types of Blocks In Forms Builder there are two main types of blocks: data blocks and control blocks. Data Blocks When you build database applications with Forms Builder, many of the blocks will be data blocks. A data block is associated with a specific database table (or view), a stored procedure, a FROM clause query, or transactional triggers. If it is based on a table (or view), the data block can be based on only one base table, even though the data block can be programmed to access data from more than one table and data sources. By default, the association between a data block and the database enables the user to automatically access and manipulate data in the database. However, to access data from other tables (nonbase tables), you need to write triggers.
• #17: Types of Blocks (continued) Data Blocks (continued) For a base table, Forms Builder can automatically perform the following actions: Creates items in the data block to correspond to columns in the table (These items are data items or base table items.) Produces code in the form to employ the rules of the table’s constraints Generates SQL at run time (implicit SQL) to insert, update, delete, and query rows in the base table, based upon the user’s actions At run time, you can use standard function keys, buttons, menu options, or standard toolbar options to initiate query, insert, update, or delete operations on base tables, and the subsequent commit of the transaction. Control Blocks A control block is not associated with a database, and its items do not relate to any columns within any database table. Its items are called control items. For example, you can create many buttons in your module to initiate certain actions and to logically group these buttons in a control block. Master Versus Detail Blocks To support the relationship between data blocks and their underlying base tables, you can define one data block as the detail (child) of a master (parent) data block. This links primary key and foreign key values across data blocks, and synchronizes the data that these data blocks display. Forms Builder automatically generates the objects and code needed to support master-detail relationships. As the designer, you need only request it. Note: If your application requires it, you can also create independent data blocks in which there is no relationship between the two data blocks. Single-Record Versus Multirecord Blocks You can design a data block to show one record at a time (single-record block) or several records at once (multirecord block). Usually, you create a single-record data block to show master block data and a multirecord data block to show detail block data. In either case, records in a data block that are currently not visible on the screen are stored in a block buffer.
• #18: Multi-Block and Multi-Form Applications Typically, a Forms Builder application consists of more than one data block. With more than one data block, you can do the following: Separate the navigation cycle of one group of items from another Map each data block to a different database table (You can have one base table per data block.) Produce a master-detail form, with a master data block and corresponding detail data blocks that are related to the master You can create a large form module with many data blocks. Alternatively, you can create several smaller form modules with fewer data blocks in each. Generally, a modular application with several smaller form modules has the following characteristics: Modules are loaded only when their components are required, thus conserving memory. Maintenance can occur on one module without regenerating or loading the others. Forms can call upon one another, as required.
• #19: Multi-Block and Multi-Form Applications (continued) Parallel development can be carried out by different team members on different components. Here are some points to consider when grouping data blocks in the application:
• #20: Technical Note A form module is made up of one or more blocks. A data block is based on a database object, such as a table or a view. A data block can contain both data items and control items. A frame can be created to arrange data block items. Each item in a block must appear on a canvas, and each canvas must appear in a window. A form module can have one or more canvases and windows. Using triggers, you can add functionality to your form. Triggers can be written at different levels in a form module. User-named program units enable you to write additional PL/SQL code through procedures, functions, and packages.
• #21: The Object Hierarchy You can create many types of objects in a form module. They are discussed in more detail in later lessons. In the following table, note that some objects are associated, even though one might not be “owned” by the other.
• #22: Customizing Your Forms Builder Session What Are Oracle Forms Developer Preferences? You can use preferences to customize some aspects of your Forms Builder session. Forms Builder Preferences There are four tabs in the Preferences dialog box. To see a description of each preference, click Help in the Preferences dialog or press the Help key ([F1] for Windows NT/95). In addition to session preferences, you can also set run-time settings that apply to running your form from within the builder. To modify preferences, perform the following steps: 1.Select Edit > Preferences. 2.Specify any options that you require. 3.Click OK to save changes, or Cancel to cancel changes.
• #23: Customizing Your Forms Builder Session (continued) You can specify several related preferences on each of the Preference tabs. The table below describes one preference on each of the tabs:
• #24: Saving Preferences When you click OK in the Preferences dialog box, Oracle Forms Developer updates your current session with the changes. When you exit the builder (File > Exit), Oracle Forms Developer writes the changes to a preference file for future sessions. The name of the preference file varies on different platforms. Oracle Forms Developer and Oracle Reports Developer share the same preference file. If the preference file already exists, Oracle Forms Developer merges its changes with the existing file. This does not affect preferences for Reports. Each option in the preference file is prefixed by the tool name to which it belongs. Example: Forms.build_before_run = onForms.welcome_dialog = on Oracle Forms Developer reads the preference file whenever you invoke Forms Builder. Oracle Reports Developer reads the preference file whenever you invoke Report Builder. Note: The preferences file is an editable text file. If possible, however, you should alter the options in the Preferences dialog box.
• #25: Invoking Online Help Facilities Oracle Forms Developer Help Options The table below describes the Help menu options in Forms Builder: You can also invoke context-sensitive online help from Forms Builder by pressing [Help] ([F1] on Windows).
• #26: Forms Developer Executables Forms Builder includes two executables (components) that you can access as the designer of applications. Forms Builder This is the application-building component of Oracle Forms Developer. You can use Forms Builder to design and store the definitions of form, menu, and library documents. While in the Forms Builder, you can invoke the other component, Forms Compiler. You must run the Forms Builder component in a GUI environment in order to use its graphical design facilities. Forms Compiler Once your form is built, use the Forms Compiler. This reads the definition of your module and creates an executable run file. Invoking Forms Builder Executables In a GUI environment, you usually store commands to invoke Forms Builder components in menus and window icons for convenient access. You can also enter these commands on the command line.
• #27: Forms Developer Executables (continued) For example: IFBLD90 [my_form] [scott/tiger@my_database] Note: Commands for invoking the product components vary according to platform. Forms Services Because Forms applications are Web based, it is not possible to run them directly from the command line. Instead, they are invoked by typing a URL into a browser or applet viewer command, directed to Forms Services. The files used at run time must already have been compiled by the Forms Compiler component. These files must reside on the middle tier machine in a directory accessible to the Forms Runtime Engine (in FORMS90_PATH). To test your applications, you also can access Forms Services directly from Forms Builder by setting certain preferences, as described later in this lesson.
• #28: Forms Developer Module Types A Forms application can consist of many modules—that is, files. A module is a major component of your application and is the basis for storage and ownership. A module owns the rest of the objects in the system. A Forms Developer module can be of the following types: Form: As the main component of an application, the form module presents the objects and data that users can see or interact with. Data items in a form are arranged into records. Menu: A menu module can consist of a hierarchy of menus, each with selectable items. PL/SQL Library: A PL/SQL Library is a collection of PL/SQL program units whose code can be referenced and called from other modules. Object Library: An Object Library is a collection of form objects that you can use in other modules. You can create it to store, maintain, and distribute standard objects that can be reused across the entire development organization.
• #29: Forms Developer Module Types (continued) Forms Builder Module Types Forms Builder provides the default menu for every form. The default menu includes commands for all basic database operations, such as insert, delete, query, and so on. If your application has specific requirements that are not met by the default menu, you can create a custom menu module. Menu modules are not functional by themselves, but when attached to form modules they can provide a service to the facilities offered by a form, as well as options to invoke facilities elsewhere. PL/SQL Library documents can contain program units that can be used by other form and menu modules. You can build an application from multiple form modules, menu modules, and library documents as needed.
• #30: Oracle Developer Environment Variables Introduction Oracle Forms Developer uses many environment variables. These have default values, all of which you can modify in your own environment for different applications. Setting Search Paths for Run Time Forms uses some environment variables set on the middle-tier machine to search at run time for files such as forms, menus, and libraries. This enables you to build applications that are portable across platforms and directory structures by avoiding hard-coded paths in file references. Forms searches the following paths in order until the required file is found: The current working directory Directories in FORMS90_PATH Directories in ORACLE_PATH Although you could set these variables at the machine level, such as in the Windows Registry, it is preferable to set them in the Forms environment file. Settings in this file override system settings for running a Forms application.
• #31: Oracle Developer Environment Variables (continued) Defining the Design Time Environment Design time environment variables help govern the behavior of Forms Builder. These environment variables must be set on the machine where Oracle Developer Suite is installed. For example, on Windows platforms you set them in the Windows Registry. Java class files: Forms Builder needs access to certain Java classes for some of its features, such as Help, the debugger, and the Java importer. You set FORMS90_BUILDER_CLASSPATH so that Forms Builder can find the Java classes it needs during development and testing of an application. Icon files: Forms Builder enables you to create buttons with iconic images. You can use .ico, .gif, or .jpg images. You set UI_ICON to the directory path where these images are located. You set the environment variable UI_ICON_EXTENSION to tell Forms Builder which type of image to display on buttons. Valid values are ico (the default), gif, or jpg. Although you can use .ico images to display on iconic buttons within Forms Builder, such images will not be displayed when running the form — use .gif or .jpg files for deployed icons.
• #32: Oracle Developer Environment Variables (continued) URL parameters: By default, when you run a form from Forms Builder, the parameters that are passed in the URL are hidden. For testing purposes, if you want to be able to see these parameters, such as the form name, you can set FORMS90_HIDE_OBR_PARAMS to FALSE (the default is TRUE) . OBR stands for one button run, a term used for running a form from within Forms Builder by clicking the Run Form button.
• #33: Oracle Developer Environment Variables (continued) Dates in Oracle Forms Developer Dates in Oracle Forms Developer applications can come from several sources: Fetched from the database Entered by the end user Defined in the application itself Date Format Masks In a later lesson, you will learn how to specify a format mask for a date item in your form. In addition to the format masks a developer might explicitly define, Forms Builder uses several of its own internal masks. The values for these internal masks can be specified with property values and environment variables. To eliminate potential errors caused by the year 2000 (Y2K), you can set environment variables that Forms Builder uses to format date items: Database date format mask: Each database session within a Forms application has a single database date format mask. A default value for this mask is established by the Oracle server’s initialization parameter. You can override this value in each new database session for a particular client by setting the client’s NLS_DATE_FORMAT environment variable.
• #34: Oracle Developer Environment Variables (continued) Date Format Masks (continued) Input date format masks: This mask (potentially, a set of masks) is used to convert a user-entered string into a native format date value. You can set the environment variables FORMS90_USER_DATE_FORMAT or FORMS90_USER_DATETIME_FORMAT to specify these format masks.For example, you could set FORMS90_USER_DATE_FORMAT to the value FXFMDD-MM-RRRR. This would force the user to enter values into date items (with no format mask) in the format exemplified by 30-06-97. The RRRR token enables years between 1950 and 2049 to be entered with the century omitted. Output date format masks: Converts dates displayed in output such as lists of values: FORMS90_OUTPUT_DATE_FORMAT or FORMS90_OUTPUT_DATETIME_FORMAT Error date format masks: Converts dates displayed in error messages: FORMS90_ERROR_DATE_FORMAT or FORMS90_ERROR_DATETIME_FORMAT
• #35: Oracle Developer Environment Variables (continued) Modifying Run-Time Environment Variables In a Windows 32-bit environment, use the Windows Registry to modify these paths, except for CLASSPATH, which is set in the System settings of the Control Panel. You can also override these settings at run time in the file that controls the Forms run-time environment, which is the default.env file unless a different file is specified. Using the Forms environment file makes it easier to deploy the application on any platform. You can specify which environment file to use in a special Forms configuration file called by default formsweb.cfg. In this configuration file, you can set system parameters, such as the name of the environment control file. You also can set parameters to control which form to run, the user ID, aspects of the Java client and the HTML file that contains the Java applet, and many other settings.
• #36: Testing a Form with the Run Form Button The Run Form menu command or button enables you to run a form module in a Web browser from within Forms Builder. This makes it easy to test your application in a three-tier environment, with all components appearing and behaving as they would for a user of the application. You must define some basic information to enable this three-tier testing environment. You set this information in the Preferences dialog that you access from Edit > Preferences. Once the Preferences dialog is open, perform the following steps: 1.Click the Runtime tab. 2.Set the Application Server URL: This must be a URL pointing to the Forms Servlet on the middle tier. Note that it is typically on the same machine where you are running Forms Builder. You can also use the config parameter to specify a named configuration in the Forms Web configuration file (formsweb.cfg by default).Example for the same machine with OC4J running on the default port of 8889:http://127.0.0.1:8889/forms90/f90servlet?config=myapp 3.Set the Web Browser Location (only needed if you want to run in a different browser than the default for your machine).
• #37: Testing a Form with the Run Form Button (continued) Note: The correct way to exit a Forms session is to exit the form (File > Exit, or click Exit), then close the browser. If you close the browser without first exiting the form, your session may hang. You will notice this because you may not be able to recompile the same form, but will receive the error: FRM-30087: Unable to create form file. If this happens, you will need to open Task Manager and end the ifweb90 process manually.
• #38: Summary With Forms Builder, an Oracle Forms Developer component, you can develop form-based applications for presenting and manipulating data in a variety of ways. Forms Builder enables screen-based queries, inserts, updates, and deletes of data. Forms Builder provides powerful GUI and integration features. Applications consist of form modules, menu modules, and library documents. Form modules consist of logical data blocks. A data block is the logical owner of items. Items in one data block do not need to be physically grouped. Items in one data block can span several canvases. Environment variables govern the behavior of: Running forms (set in the Forms environment file) Forms Builder (set on the development machine, such as in the Windows Registry for Windows platforms) You can run a form application from within Forms Builder in order to test it in a browser. You specify the URL to use in the Runtime tab of the Preferences dialog box.
• #40: Practice 3 Overview In this practice you become familiar with Oracle Forms Developer by performing the following tasks: Examining the Object Navigator in Forms Builder Setting Forms Builder preferences Using the Layout Editor in Forms Builder to modify the appearance of a form. In addition, you set run-time preferences to use OC4J to test your application on your local machine. You also set environment variables so that images display on iconic buttons in the Layout Editor of Forms Builder. Note: For solutions to this practice, see Practice 3 in Appendix A, “Practice Solutions.”
• #41: Practice 3 1.Invoke Forms Builder. If the Welcome page is displayed, select “Open an existing form”. If the Welcome page is not displayed, select File > Open. 2.Open the Orders.fmb form module from the Open Dialog window. 3.Set your preferences so that Welcome dialogs display when you first open Forms Builder and when you use any of the wizards. 4.Close the Orders form. 5.Open the Summit.fmb form module. 6.Expand the Data Blocks node. 7.Expand the Database Objects node. If you cannot expand the node, connect to the database and try again. What do you see below this node? 8.Collapse the Data Blocks node. 9.Change the layout of the Summit.fmb form module to match the following screenshot. At the end, save your changes. a.Invoke the Layout Editor. b.Move the three summit shapes to the top-right corner of the layout. Align the objects along the bottom edge. c.Select the summit shape in the middle and place it behind the other two shapes. Draw a box with no fill around the summit shapes. e.Add the text Summit Office Supply in the box. If necessary, enlarge the box. f.Move the Manager_Id and Location_Id items to match the screenshot. g.Move the First_Name item up to align it at the same level as the Last_Name item. Resize the scroll bar to make it the same height as the three records in the Employees block. Save the form module.
• #42: Practice 3 (continued) 10.Set the run-time preferences for Forms Builder to use OC4J to test your applications. Set the Application Server URL by pressing Reset to Default, which will enter the following settings: 11.In Forms Builder, open and run the Customers form located in your local directory (you must have OC4J running first).Note: Run-time fonts may look different than the fonts used in Forms Builder because Forms Builder uses operating system–specific fonts, but at run time only Java fonts are used. In addition, the appearance is different from the Layout Editor because the Oracle (rather than the generic) look and feel is used by default. Click the Account Information tab. You should be able to see the image of a flashlight on the List button. Exit the run-time session and close the browser window. In Forms Builder, open the Layout Editor for the CV_Customer canvas by expanding the Canvases node in the Object Navigator and double-clicking the CV_Customer canvas icon. In the Layout Editor, click the Account Information tab. What do you observe about the List button? From the Windows Start menu, choose Run, type regedit, and click OK. Expand the registry nodes HKEY_LOCAL_MACHINE > SOFTWARE > ORACLE. Click into the ORACLE node, or into one of the HOME nodes beneath it; your instructor will tell you which node to open. Ensure that you have opened the correct node by verifying that the key FORMS90 exists in that node. Set the path for Forms Builder to locate icons:a) Double-click the UI_ICON key to open it for editing.b) For the value data, append the path to the .gif file that you will use for the button icon, which is the \icons subdirectory of your lab directory. Separate this path from the remainder of the string with a semicolon; for example: ;e:\labs\lab\icons, then click OK. In a similar fashion, set the value for Forms Builder to use for the icon extension, then close the registry editor. Close and reopen Forms Builder. Open the Customers form and verify that the flashlight icon now displays in the Layout Editor.