|
The objective of Oracle Power Objects (OPO) is database application development. At the highest level, OPO consists of the following three object types: applications, sessions, and libraries. Since application development is OPO's focus, the application
object (application) is the core component of OPO. Sessions act as a database interfaces for applications and libraries. Classes are used for storing reusable application resources. This chapter will provide a better understanding of the components within
an application object and how they interact with the OPO environment.
OPO organizes its components within a folder metaphor. Within a session are database objects. Within a library are reusable classes and bitmaps. This same metaphor applies to applications, as they contain other objects. An application consists of
properties, methods, and objects that define the interface and actions of that application.
Applications are constructed using forms, reports, classes, bitmaps, and OLE objects. Applications interface with users through forms and reports. Each form and report is built by constructing screens that the user will see by creating and organizing
objects, and controls to display information, data, and control options. The user navigates through the forms and reports accomplishing whatever tasks the application provides.
As with any other object in OPO, the application object has properties and methods. These properties and methods determine how the application, as a whole, interacts with the database and performs certain actions.
The properties specify the name, label, and default session for the application. Additionally, the declarations property is used to declare global variables, constants, and external functions that are used in the application. Table 39.1 is a list of the
application properties:
Table 39.1. Applications properties.
Property
|
Description
|
|
(Declarations)
|
Section where global variables, constants, and external functions such as Dynamic Link Library (DLL) and Code Fragment procedures are declared.
|
|
DefaultSession
|
The name of the default session object to be used for database interaction. If an object does not specify a particular session, the DefaultSession will be used.
|
|
Label
|
The text you will see in the title bar of the main OPO window when the application is run.
|
|
Name
|
The identifier used to refer to this application. |
The methods of an application provide the ability to initialize components and specify what actions occur when the application starts and ends. An application's methods also allow the developer to customize toolbar and menu bar actions. Table 39.2 is a
list of the application methods:
Table 39.2. Application methods.
Method
|
Description
|
|
CloseApp
|
Use this method to call to quit the application. It can be used to ask the user if they are sure they want to quit, to complete processing, or to clean up the application before exiting.
|
|
DoCommand
|
This method is called when the user selects a toolbar button or menu command. It can be used to override default toolbar or menu bar processing or to perform actions for custom toolbars or menu bars elements.
|
|
Initialize
|
This method is the first method called when an application runs. This method is invoked for both Run App and Run Form. It can be used to initialize variables or objects.
|
|
LastWindowClosed
|
This method is called when the last open window is closed. It indicates that the user didn' t specifically quit the application, but that the last window was closed. The developer can either allow the application to quit or continue the application by
opening another window.
|
|
OnLoad
|
This method is called when starting the application. More precisely, it is called when the application is loaded into memory. This method is invoked by Run App, not by Run Form. It is used to initialize variables and objects specific to the application.
This method should also tell the application which form(s) to open initially.
|
|
TestCommand
|
This method is called when the OPO draws the toolbar and menu bar. It is used to determine which toolbar buttons and menu items are enabled or disabled. It can be used to override the default system processing or to indicate the enabled/disabled status
for custom toolbar or menu bar elements. |
Forms, reports, classes, bitmaps, and OLE objects are the major components that makeup an application. The specific set of these objects that comprise any given applications are displayed as icons in the applications window. Figure 39.1 illustrates an
application named SAMPLAPP that contains one of each of the main application objects:
Figure 39.1. An application's objects.
Each of these components, which are objects themselves, can be comprised of other objects. Within OPO there is a form designer, a report designer, and a class designer. These designers are used to create forms, reports, and classes that incorporate
graphical and data controls that convey information to the user.
Forms are the core application object. Each form represents a screen that can be viewed by the user. This screen may display data or other information, it may require input from the user, it may provide navigational control, it may simply draw a
picture, or it may do all of the above. In any sense, a form interacts with the user for displaying information and receiving feedback.
Reports display data in a presentation manner. Reports are designed and look similar to forms, so they can contain essentially the same information as a form. However, the user cannot directly interact with reports. Reports simply provide a way to view
and print data from an application.
Classes are a very powerful concept within OPO. They are reusable, object-oriented components that can be incorporated into forms, reports, or other classes. A class is basically a self-contained form. Its design, look, and functions are exactly like a
form. Classes are generally created to perform task that are used multiple times by different forms. A simple example would be an exit button. If each form of an application required the same code to be activated on the Click method of an exit button, then
a class containing an exit button with the appropriate code could be created and instanced on each form. Each instance of the class can be customized, yet tied to the parent class. If the code for this button changes, only the code in the parent class
would need to be changed.
Bitmaps are simply graphic bitmaps used to add imagery to application objects. Forms, reports, classes, and buttons can display bitmaps by setting the Bitmap property of the object to the name of the bitmap, or by dropping the bitmap onto the object.
Currently, OPO only supports the Windows BMP file type. In future releases, OPO will permit Mac PICT files and other file types to be imported as bitmaps.
OLE objects are instances of another software's objects that can be embedded into a form, report, or class. Object Linking and Embedding (OLE) allows different software, that are OLE enabled, to share components. For example, a Microsoft Word (Word)
document and functionality can be used in an OPO form. The instanced document has the same look and feel as it does in Word, and when the instance of the document is selected, the menu bar and toolbar of Word are incorporated into OPO. There are many
different products that can be included in an OPO application through OLE, including Excel, PowerPoint, Video for Windows, Sound, Paintbrush, and any other installed product that is an OLE Server.
Once an application is completed, the application can be run by clicking on the Run App toolbar button, or by selecting the Run | Run Application menu command. This causes OPO to compile the application objects to program code (p-code) and run the
application. If any errors exist, the compiler will stop its execution, notify the developer, and highlight the error in the designer. Additionally, each form and report can be run individually for faster testing. With the form or report open, click on the
Run Form/Report toolbar button, or select the Run | Run Form menu command. This will quickly compile the code for just this form or report and run it. This prevents from having to compile the entire application when working with a single form or report.
Note, you cannot run a form or report by itself if it relies on other forms, nor can you navigate to other forms or reports simply because only that form or report has been compiled.
After running and testing an application, it's ready to be distributed. The first step in distributing an application is to compile it. Clicking on the Generate Executable toolbar button invokes the Generate Runtime File Dialog Box, which is illustrated
in Figure 39.2.
Figure 39.2. Generate Runtime File dialog box.
This dialog allows the application to be compiled to a separate application file, or as a stand-alone executable file. This dialog can be bypassed by selecting either the Run | Compile Application or Run | Generate Executable menu commands.
Creating a separate application file compiles the application and writes just the compiled p-code to a Power Objects (PO) file. This file can be executed using the OPO Runtime (PWRRUN.EXE). Compiling to a stand-alone executable first compiles the
application to p-code, then binds it to a minimized copy of the OPO Runtime. This creates a self-sufficient executable (EXE) file. In either sense, the compiled application is executed via the OPO Runtime. Don't worry, the OPO Runtime is freely
distributable which is something new for Oracle.
The advantage of compiling separate application files is size. The PO files are small, generally 25-100 Kbytes The EXE files tend to be greater than 2 Mbytes. If several applications are to be compiled and distributed together, it makes sense to compile
separate application files and simply distribute them and the OPO Runtime. The user simply needs to start the OPO Runtime and specify which PO file to run. However, it's easier for the user to simply run a single executable, which is why stand-alone
executables are often preferred.
If compiling separate applications files, the PO and PWRRUN.EXE files will need to be distributed. Otherwise, if compiling stand-alone executables, only the EXE file needs to be distributed. Other files that need to be distributed are database files and
any external function files used by the application. If the application uses a Blaze database, the file that was created for the Blaze database file needs to be distributed. If the application runs against an Oracle, Sybase, or SQLServer database, then the
corresponding Power Objects Database (POD) file needs to be distributed with the application. Additionally, if the application references any Dynamic Link Library (DLL) functions, then the associated DLL file needs to be distributed. Other files, such as
session and library files, shouldn' t be distributed, since they are compiled into the PO and EXE file.
Power Objects is designed to facilitate rapid application development and deployment of database applications. The application model uses three conceptual building blocks to accomplish this goal. The session object provides a connectivity layer to
database back ends. The library object provides access to application-level objects to enhance standardization and to promote object reuse. Finally, the application object represents the set of related activities that make up the application. With these
three conceptual objects, a developer can maintain each conceptual area independently of the others and produce database applications to meet their current and future needs.
|
