The Debugger Tab is located in the lower pane of Service Studio and allows you to track all threads being debugged and examine module elements and runtime values. This tab is automatically shown when the debugger is active and the execution flow hits a breakpoint.
The Debugger Tab contains three main areas:
- The debugging context area (1);
- The scope tabs area (2);
- The Debugger Toolbar (3).
It's located in the top right section of the Debugger Tab and provides you with a set of debugging commands to trace the execution of the thread being debugged.
The available buttons in the toolbar are the following:
|Debug in the Public Area||Starts the debugger in the Public Area. If debugging a mobile app, Service Studio launches a special Chrome browser instance that must be used for debugging it.
Learn more about Public and Personal Areas.
|Stop Debugging||Stops the debugger and resumes the execution of all of the suspended threads.|
|Suspend Running Server Threads||Suspends the execution of all current server threads in the Platform Server.|
|Abort Running Server Threads||Aborts the execution of the current server threads in the Platform Server.|
||Resumes the execution.|
||Steps the execution trace to the next element in the same flow or screen "level".|
||Steps the execution trace to the first element "inside" elements like:
— Execute Process elements;
— Execute Client Action (or Execute Server Action) elements which execute user-defined actions;
— User functions;
— Assignments of Assign elements.
Trying to step into any other element is the same as doing a Step Over operation.
||Continues the execution trace to the next element in the outer "level" of the flow or screen, i.e. it "gets out" of the current flow or screen.|
|Break On All Exceptions||When active, this toggle button forces the debugger to suspend the execution of threads whenever handled or unhandled exceptions occur.|
While debugging web applications you can also define breakpoints in widgets. The step commands mentioned above ( Step Over, Step Into and Step Out) have a particular behavior on widgets:
They don't stop on widgets unless the widget has a breakpoint, or is designed using elements that are evaluated at runtime as, for example, widgets designed using user-defined functions;
The order that step commands follow widgets on the screen is the same by which they are rendered and not the order the widgets are displayed on the screen.
Debugging Context Area
Located on the left-hand side of the Debugger Tab, this area contains several tabs containing information about the debugger execution.
You can double-click on elements listed in these tabs to show them on the canvas. However, if the module element being debugged does not belong to your module (e.g. a module reference, an action in a producer module, etc.), it cannot be visualized on the canvas, and will only be displayed in the Threads Tab with its name followed by its module name between brackets.
- Threads Tab
- This tab shows the current debugging context. It lists all the threads being debugged and their debugging context: module element (if applicable), event, UI flow, screen or block, and client/server action(s) that make up the call stack. The action executed last is listed at the bottom of each thread entry.
- Breakpoints Tab
- Lists all breakpoints defined in the module. The breakpoints are listed alphabetically.
- Users Tab
- Lists all the other users that are also debugging server threads in your module. You may expand each user to see the list of threads being debugged by him.
If there are any unpublished changes to the module you're currently debugging, the modified module elements will have the following visual cues in the Threads Tab:
Missing element: the element is no longer present in the module but it still exists in the published version of the module. The missing element will still be debugged, but it will not have visual feedback on the canvas;
Modified element: the element is different from the one that was published. The element that is going to be debugged is the published one, not the modified one.
Switching to Another Thread
The thread being debugged, i.e. the active thread, is identified by a blue arrow in this tab, as well as the module element being debugged on canvas. Every other thread that may also be suspended (but inactive, as they're not being debugged) is marked with a grey arrow, as well as their module element on the canvas (if visible).
To switch to another thread, double-click on the thread you want to debug in the Threads Tab; Service Studio updates the contents of the Debugger Tab with the debug information for that thread.
Learn more about threads in the Threads topic.
Scope Tabs Area
Located on the right-hand side of the Debugger Tab, this area contains several scope tabs displaying module elements and runtime values for you to examine while the execution is suspended during a debug session.
All elements shown in scope tabs are listed in alphabetical order in the tabs. Some elements can be expanded to examine inner elements value, e.g., the
Name in a
Customer Record. Values presented in red are the ones that have changed since the last debug step.
You can also double-click on a element to open a window displaying its value. This allows you to:
- Check a value that is too long to be examined directly in the tab;
- Display a table of values for elements of List data type.
- In Use Tab
- Lists all elements from the scope tree relevant for immediate examination regarding the module element currently being debugged.
- Locals Tab
- Lists all elements that are scope locals of the module element currently being debugged.
- Widgets Tab
- Lists all widgets in scope of the module element currently being debugged.
- Session Tab
- Only available for web applications. Lists all session variables of the module.
- Site Tab
- Lists all site properties of the module.
- Watches Tab
- Lists all variables explicitly marked as watched.