Event Break Conditions
An event break condition causes the application to pass control to the Debugger at the beginning of the associated event block. You set event break conditions on the Breakpoints: Events, Errors and Threads portlet (Other portlet tab) of the Debug tab.
You can set event break conditions for the following events:
All Events
Set this condition to turn on all of the event's break conditions at once.
Recognized User Events
Set this condition for a defined OpenROAD user event.
OpenROAD activates the Debugger just before any user event block executes.
Unrecognized User Events
Set this condition for a user event that is not defined for OpenROAD.
OpenROAD passes control to the Debugger when a frame receives a user event for which it has no user event block or for which it is not explicitly waiting (that is, there is no WaitFor method waiting for that user event).
The Unrecognized User Event helps catch common programming errors that result from a frame's receiving a user event for which it has no corresponding event block. The frame does not recognize the event and ignores it. This situation can occur because the event block is missing or the user event name is misspelled, either in the event block or in the SendUserEvent statement.
DB Events
Set this condition for database events.
The application passes control to the Debugger just before any database event block executes.
Window Manager Events
Set this condition for any event that is not a user or database event. Entry events, for example, are window manager events.
The application gives control to the Debugger just before the execution of any event block defined for a window manager event, that is, all event blocks except those for user or database events.
If a particular window event has no defined event blocks in the application, that event, if it occurs, does not cause a break in the application.
Set Event Break Conditions
You can set event break conditions on the Breakpoints: Events, Errors and Threads portlet (Other portlet tab) of the Debug tab.
To set event break conditions
1. Click the Develop tab and select the application in which you want to set event break conditions in the Applications portlet.
2. Click the Debug tab.
3. Click the Other portlet tab on the right side of the Workbench window.
The Breakpoints: Events, Errors and Threads portlet is displayed.
4. In the Event Break Conditions section, select one or more types of events that you want to set as break conditions, or check All Events to set break conditions for all events.
Event break conditions are displayed in the Activations portlet of the Debug tab.
If you want to deactivate or reactivate a break condition, clear or select the appropriate check box in the Activations portlet.
Break on Event Dialog
When the Debugger encounters an event break condition that you set, OpenROAD stops the application execution and turns control over to the Debugger, which displays the Break on Event dialog containing the name of the event. The ability to edit user and database events is helpful when you are debugging because you can manipulate the event before it is executed.
Depending on the type of event that was intercepted, the format of this dialog and the options for further debugging will vary. If the event named is a user or a database event, you can edit the event and then click a button on the dialog to control the next step in the event break execution.
For a break on a user event, you can also edit the event's name and three of its message parameters (messageinteger, messagevarchar, and messagefloat). For a database event, you can edit the name or text of the event. For window manager events, you can only use the buttons to process the event.
If the event that caused the break is part of an event chain, the message at the top of the dialog does not necessarily name the actual event in the chain that caused the break. To see this name, click the Break button.
The buttons on the Break on Event dialog provide the following options:
Break
Continues the event break execution.
It displays the Debugger window positioned on the first statement in the event block for the event that caused the break. From here, you can perform all of the Debugger functions available from the Debugger window. For more information about the Debugger window, see How You Can Debug Applications.
In the case of chained events, the block on which the Debugger window is positioned may not be the block that is named in the message on the Event Break Conditions dialog.
Ignore
Skips the event named in the dialog.
If you select this option, execution continues as if the event did not occur.
Continue
Executes the event.
The application does not stop until the next break condition is encountered.