Running an application
When the application seems to be working correctly, you are ready to run it in regular mode. In regular mode, the application responds to user interaction and continues to run until the user exits the application or a runtime error occurs. You can rely on the default runtime error reporting by PowerBuilder or write a script that specifies your own error processing. You can also generate a diagnostic trace of your application's execution.
For how to analyze your application's logic and performance, see Chapter 31, "Tracing and Profiling Applications "
Running the application
To run an application:
- Do one of the following:
- In the System Tree, highlight a target and select Run from the pop-up menu
- Click the Run or Select and Run button on the PowerBar
- Select Run>Run or Run>Select and Run from the menu bar
The Run button runs the last run or debugged target. The name of the current target is displayed in the Run button tool tip. The Select and Run button opens a dialog box that lets you select the target to run.
PowerBuilder becomes minimized and a button displays on the Taskbar. Your application executes.
To stop a running application:
- End the application normally, or double-click the
minimized PowerBuilder button or icon to open a response window
from which you can terminate the application.
Handling errors during execution
A serious error during execution (such as attempting to access a window that has not been opened) will trigger the SystemError event in the Application object if you have not added exception handling code to take care of the error.
If there is no SystemError script
- The number and text of the error message
- The line number, event, and object in which the error occurred
There is also an OK button that closes the message box and stops the application.
If there is a SystemError script
If there is a script for the SystemError event, PowerBuilder executes the script and does not display the message box. Whether or not you have added TRY/CATCH blocks to your code to trap errors, it is a good idea to build an application-level script for the SystemError event to trap and process any runtime errors that have not been handled, as described in "Using the Error object".
For more information about handling exceptions, see Application Techniques .
Using the Error object
In the script for the SystemError event, you can access the built-in Error object to determine which error occurred and where it occurred. The Error object contains the properties shown in Table 30-3.
Defining your own Error object You can customize your own version of the Error object by defining a class user object inherited from the built-in Error object. You can add properties and define object-level functions for your Error object to allow for additional processing. In the Application painter, you can then specify that you want to use your user object inherited from Error as the global Error object in your application. For more information, see "Building a standard class user object".
Runtime error numbers
Table 30-4 lists the runtime error numbers returned in the Number property of the Error object and the meaning of each number:
Some errors terminate the application immediately. They do not trigger the SystemError event.
SystemError event scripts
A typical script for the SystemError event includes a CHOOSE CASE control structure to handle specific errors. To stop the application, include a HALT statement in the SystemError script.
Caution You can continue your application after a SystemError event, but doing so can cause unpredictable and undesirable effects. Where the application will resume depends on what caused the error. Typically, you are better off reporting the problem to the user, then stopping the application with HALT.
To test the SystemError event script:
- Assign values to the properties of the Error object
with the PopulateError function.
- Call the SignalError function to trigger the
The script for the SystemError event executes.