Application Development

In the process of development, Panther allows you to simulate how your application behaves and appears to end users via test mode. From test mode, you can return to the editor, make changes to your application, and resume testing without exiting from the executable.

There are two Panther executables, prodev and prorun (prodev32/64.exe and prorun32/64.exe in Windows).

• When starting prodev, you are in the editor where you can begin creating your Panther application. To test an application component, bring focus to it and choose FileTest Mode (or the Test Mode button on the toolbar). The status bar displays Test Mode.

• When starting prorun, you are in application mode. Access to the editor is not available.

Test Mode Menu Bar

Once test mode or application mode is entered, the menu displays the default application toolbar. If your application has its own menu bar/toolbar, the Panther menu is not displayed.

The following menu options are available while in test mode:

Edit menu

Provides basic editing commands (not available in character-mode platforms) that you can use while you are testing your applications.

Options menu

Includes the following options:

• Top Screen—Accesses the top-level screen of your application, or the initial screen displayed when you entered test mode. This option clears all other screens from the form and window stacks.

• System Commands—Available only in character mode platforms. Allows you to execute operating system commands from within Panther. Enter the command, and choose OK to execute it. When the command terminates, press any key to return to test mode.

• Open Screen —Invokes the dialog box where you can choose to open any screen—as a form, a window, or sibling window. This allows you to jump anywhere within your application.

• Editor —Invokes the editor.

• Debugger —Invokes the Panther debugger. For instructions, refer to Chapter 39, "Using the Debugger."

Keys menu

Provides access to Panther's logical keys and their functions. These are useful if your application screen does not provide other methods for carrying out commands, such as Exit, Transmit, Switch scope, or Zoom keys.

Windows menu

Allows you to bring focus to any screens that are currently open.

Transaction menu

Provides access to transaction manager commands that you can use with screens that are derived from your database. The commands are:

• View—Select one or more records for display purposes only.

• Select—Select one or more records for possible update.

• Continue—Fetch the next group of selected records (in two-tier applications only).

• New—Close the current transaction (if any), and clear existing data, to allow a user to enter information to create a new record.

• Copy—Close the current transaction (if any), without clearing existing data, to allow a user to create a new record from the existing data.

• Save—Update the database to reflect the changes or additions made by a user.

• Close—Terminate the transaction in progress

• Clear—Clear transaction data (that is, data entered in a field) from the screen. This applies only when adding a new record or when entering criteria for selecting records.

Refer to Chapter 34, "Specifying Transaction Manager Commands," for information on writing transaction manager commands.

Database menu

Allows you to connect to, as well as disconnect from, databases. The Trace On/Off command allows you to toggle the display of SQL statements that are automatically generated by way of the transaction manager commands.

Refer to Chapter 33, "Using Automated SQL Generation," for information on setting properties that take advantage of Panther's automatic SQL generation.

Middleware Session menu

(JetNet/Oracle Tuxedo only) Allows you to open, as well as close, a middleware session.

Report menu

Allows you to run, view or print out a report previously saved in a metafile (refer to "Running Reports from the Report Menu" in Reports).

Testing Application Components

You can test your client screens and service components through a direct or remote connection to the database. You need to be in test mode to test how your application components and their contents function.

Notes: If the screen you are testing references other screens, the referenced screens will not be viewable unless you saved them to a library before entering test mode. Also, if you go into test mode without saving changes to the referenced screens, you will only see the last saved version of the referenced screen and not the unsaved changes.

When you want to test a screen, you bring focus to it and choose FileTest Mode (or the Test Mode button on the toolbar). If you have other open screens in your Workspace with unsaved changes, you are prompted:

Do you want to save changes to <screenName>@libraryName?

Choose the desired action:

• Yes—Saves the screen with its given name to the appropriate library.

• Yes to all—Saves all open screens (except for the one you want to test and untitled screens).

• No—Does not save the changes, but the changes are not lost. You can save the changes when you return from Test mode.

• No to all—Does not save the changes of any of the open screens, but the changes are not lost. You can save the screens when you return from Test mode.

• Cancel—Cancels the test request.

The active screen opens in Test mode.

Notes: Test mode is virtually identical in appearance and function to Application mode, except that when you exit Test mode you return to the screen editor.

Testing Screens and Service Components

In a two-tier architecture, you need a direct connection to the database to test your screens; however, in a three-tier architecture, you need a remote connection to the database to completely test your client screens.

Before you test your three-tier client screens, you must save the corresponding service components and selection service components (if any) to their appropriate libraries. For JetNet and Oracle Tuxedo applications, you must also define the services in the JIF.

You can test client screens and service components via a direct or remote connection to the database. You can test your service components with a direct database connection to check whether the appropriate data is passed from the database. A remote database connection is established by configuring and running servers which access the database and provide services.

Service Components

You can test a service component to see if the appropriate data is passed from the database to the service component. This requires a direct database connection rather than connecting to the database by way of the application server.

How to Test a Service Component with a Direct Database Connection

1. Bring focus to the screen you want to test by clicking on it.
2. Choose FileTest Mode (or the Test Mode button on the toolbar).

   The active service component opens in Test mode. Any changes (saved or not) made to the service component are reflected in Test mode.

3. Choose DatabaseConnect to connect to the database.

   While in test mode you can:

   • Test database transactions via the Transaction menu option.

   • If the Panther debugger is linked into your application or authoring executable, invoke the debugger window by pressing the DBUG logical key. (Refer to Chapter 39, "Using the Debugger," for more information.)

4. Choose OptionsEditor or press the Panther Exit key twice to exit Test mode. You return to the editor, with the workspace restored to the way it was when you exited to Test mode.

Save the service component to the server library and then you can test it with client screens.

Three-tier Client Screens

The main purpose of testing a client screen with a remote database connection is to see whether service requests are carried out and the appropriate data is returned to the client. However, to test a client screen in this manner, you must do the following as prerequisites:

• Test and save the corresponding service component to the server library.

  Notes: It is recommended that you adopt a naming convention that identifies client screens with their corresponding service components or vice-versa.

• Update the JIF as follows (JetNet/Oracle Tuxedo only):

  • Ensure that the service name specified in the JIF is the same as the service name specified in the Service property for table view widgets and link widgets on the client screen and selection screens (if any).

  • Check to see if the procedure name is accurate.

  • Check to see if the name of the service component is accurate.

  • Ensure that the service routine specified in the Service property for table view widgets on the client screen and selection screens (if any) matches the transaction type specified in the JIF.

Now, test the client screen.

How to Test Client Screens with a Remote Database Connection

1. Bring focus to the screen.
2. Choose FileTest Mode (or the Test Mode button on the toolbar).

   The active screen opens in Test mode.

3. Choose Middleware SessionConnect to connect to the middleware if you are not already connected.

   While in test mode you can:

   • Try out the screen to see if it operates as planned. Check the tabbing order, data entry formats, control strings, expressions, etc.

   • Invoke screens attached to the current screen; however, unsaved changes made to other screens are not reflected in Test mode.

   • Test a menu bar and toolbar that you attached to this screen.

   • Test database transactions via the Transaction menu option, Commands menu option (if you specified a menu bar), or push buttons.

   • If the Panther debugger is linked into your application or authoring executable, invoke the debugger window by pressing the DBUG logical key. (Refer to Chapter 39, "Using the Debugger," for more information.)

4. Choose OptionsScreen Editor or press the Panther Exit key twice to exit Test mode. You return to the screen editor, with the workspace restored to the way it was when you exited to Test mode.

The main purpose of testing a client screen with a direct database connection is to test database transactions via the Transaction menu. You check to see if the appropriate data is passed from the database to the client screen.

How to Test Client Screens with a Direct Database Connection

1. Bring focus to the screen by clicking on it.
2. Choose FileTest Mode (or the Test Mode button on the toolbar).

   The active screen opens in Test mode.

3. Choose DatabaseConnect to directly connect to the database if you are not already connected.

   While in test mode you can:

   • Try out the screen to see if it operates as planned. Check the tabbing order, data entry formats, control strings, expressions, etc.

   • Invoke screens attached to the current screen; however, unsaved changes made to other screens are not reflected in Test mode.

   • Test a menu bar and toolbar that you attached to this screen.

   • Test database transactions via the Transaction menu option, Commands menu option (if you specified a menu bar), or push buttons.

   • If the Panther debugger is linked into your application or authoring executable, invoke the debugger window by pressing the DBUG logical key. (Refer to Chapter 39, "Using the Debugger," for more information.)

4. Choose OptionsEditor or press the Panther Exit key twice to exit Test mode. You return to the editor, with the workspace restored to the way it was when you exited to Test mode.

1. Bring focus to the screen by clicking on it.
2. Choose FileCloseScreen.

   If you made changes to the screen, and have not saved them, the following message appears:

   Do you want to save changes to <screenName>?

   • Choose Yes to save the screen. If the screen is new, the Save As dialog box opens where you can name the screen in a library.

   • Choose No to close the screen without saving your changes.

   • Choose Cancel to keep the screen open.

1. Choose FileExit.

If you have changed any open screens and have not saved them, Panther prompts you to save them now.

How to Exit Application Mode

Choose Close or Quit from the system menu.