Concept : Understanding Simulate and Debug 
Contents |
[edit] Description
From the Design Editor, you can simulate/test (run) or debug a form witihn a project., or you can simulate or debug your entire application. When you simulate or debug, you are actually running your form or application in the same type of environment your end-users see at run time. All aspects of your project are "live."
[edit] Choosing Simulate or Debug
In order to simulate or debug in Bungee Connect, you must display a form or page in the Design Editor. You choose whether to simulate or debug by clicking one of the two buttons on the toolbar at the top of the Design Editor:
Run—simulates the form (and related functionality) currently visible in the Design Editor window
Run with debug—simulates the current form, but also invokes the debugger window and allows you to step through any break points you have added to your code.
[edit] Preparing to Debug
The debugging facility in Bungee Builder enables you to set breakpoints to interrupt code execution when you test your code.
Note If you do not set breakpoints in your code, when you click Run with debug, although the Debugger window is invoked, your application functionality is simulated without interruption, just as if you had clicked the Run button, however events still show up in the Event Viewer portion of the Debugger window.
[edit] Understanding Breakpoints in Bungee Connect
Breakpoints are useful for examining the state of your application at a specific point. You can set a breakpoint by selecting a code statement and then selecting the Set Breakpoint property in the Property Editor. You can set as many breakpoints as you require.
Note Breakpoints and comments are mutually exclusive. If you comment out a line of code cointaining a breakpoint, the breakpoint is immediately disabled and is no longer visible. When you run the code, the line does not execute or show a breakpoint. Once you remove the comment, the breakpoint on that line becomes active again. In addition, breakpoints do not work within OnInit, OnCreate, or any other initialization code.
[edit] Setting Breakpoints in your Main run Function
If you want breakpoints to work in your main function, you must select the Debug breakpoints set in Main property (accessible on the General tab of the Property Editor) when you select a solution.
When you select this property, you can set and debug breakpoints within the workflow of the run function of your Main class. However, with the Debug breakpoints set in Main property selected, trying to debug any form in the system gives you the following error message: This form is autogenerated by the Debugger. This dialog comes up when you have selected to debug only the Main function of your form. You can however, set both Log Messages and Dialog Messages within a run function and use these to debug your run function. A dialog message within a run function does display properly.
With the Debug breakpoints set in Main property selected, the postRenderInit function is never called. To debug your afterRenderInitialization function (or any other functions), you must clear the Debug breakpoints set in Main property.
Note Unless you set the Debug breakpoints set in Main property, breakpoints do not take affect until the application's main function completely executes.
[edit] Understanding the Debugger Window
Once you have set breakpoints in your code, you can debug your application or project by opening a form within the Design Editor, then clicking Run with debug. The Debugger window then appears with your simulated form non-modally displayed on top. In order to effectively debug, you should move your simulated form to one side of the debugger window so that you can see both your application interface and the Debugger window as you debug.
[edit] Debugger Right Side—Breakpoints and Watch Window
As you begin working with simulated functionality, when a breakpoint is encountered, your simulated execution halts and a message is generated that tells you to click the Continue button (in the Debugger window) to continue executing your code. At the same time, the code that contains the breakpoint is opened, or brought into focus in the upper right of the Debugger window. Also, a "watch window" appears in the lower right of the Debugger window. This "watch window" displays the values of variables local to the breakpoint you set. After you inspect the values of your variables, you can "step through" your code by clicking the Continue button on the Debugger window and view the value of the variables at each breakpoint you set.
[edit] Debugger Left Side—Event Viewer
The Event Viewer embedded in the left side of the Debugger window tracks events as you interact with the Bungee Builder. The Event Viewer can prove very helpful as you are debugging an application, particularly for inspecting:
- [XML] debugging messages in SOAP responses. For more information, see the Debugging XML section of Working with WSDL Files
- [SQL] error messages. For more information see Debugging SQL
- Log Messages. For more information, see Logging below.
The are several types of event icons available in the Event Viewer:
Events
Debug (Log)
Information (Log)
Warning (Log)
Error (Log)
Fatal (Log)
Note To see more of the Event Viewer portion of the Debugger window, select one of the separator bars with your mouse and drag in the direction in which you want to expand the view.
[edit] Event Viewer Toolbar
The toolbar at the top of the Event Viewer has two buttons and a text edit box labeled Show. In the Show text edit, you type the maximum number of events you want to display in the Event Viewer at one time. The two buttons (from left to right) are:
- Clear all events—Use the Clear all Events button to remove all currently displayed events from the Event Viewer.
- Filters—Use Filters (see below) to open a window that allows you to select the types of Log Messages and Events that you want to exclude from the Event Viewer. Selecting items to filter out does not effect items already in the Event Viewer; the filter is applied to future events and messages. The types of events displayed in the Events filter list are dependant on what events have already appeared within the Event Viewer.
.png)
[edit] Event Viewer Window
In addition to the Event Viewer Toolbar (see above), below the separator bar at the bottom left of the Debugger window, you can click the details button [...] to launch a separate Event Viewer window for a more unobstructed view of the field names and their values involved in the generation of individual events. The actual size and shape of the Event Viewer window depends on the type of event you are viewing. For intance, database events take up more horizontal space than other events, since the database table values for that event take up more horizontal space than vertical.
[edit] Logging
Logging your program's state during execution is useful for debugging your application. To implement logging within your Bungee Logic code, use a Log Message statement. To view the log message, you can either set up the log message to display in a modal dialog that halts the execution of your application, or set up the log message to be displayed in the Debugger window in the Builder. To have the log message appear in a modal dialog window, change the Type property to Dialog. To have the log message go to the Debugger window, set the Type property to Log.
If you use the Message property, you can cause the message to display the value of a field. For example, if you set Message to Expression and add something like: "This is the firstName field: " + firstName, the log entry will show the string produced by the expression.
When you run your project and a Log Message statement is executed that throws an event, an entry is added to the Event Viewer portion of the Debugger window. Double-click on the Event Viewer entry to see the log message details in the Event Viewer details pane. The details pane also shows the current state of the fields in the class in which the log message was executed.
Important The values shown are the values at the time you click on the log entry—not the values when the Log Message statement was executed.
[edit] See Also
Simulating Your Project or Application
Using Debugging
Setting up Logging
Debugging SOAP
Debugging SQL
