Troubleshooting a Jaguar component
When you are building a PowerBuilder custom class user object
as a Jaguar CTS component, you can use the PowerBuilder debugger
to debug the Jaguar component. You can debug the component whether
you use the live editing feature in the User Object painter or the
Project painter to deploy the component to the Jaguar server.
For more information about live editing, see “Live editing”.
Getting ready to debug a component
Before you begin debugging a remote component, check that
your configuration meets the following requirements:
- The PowerBuilder remote debugging package (PBDebugger) is
installed on the same Jaguar server as the component you want to
debug. - You are using the same version of the application
and PBLs as were used to develop the deployed component. If you
want to debug several deployed components in the same session, they
must all have been built using the same versions of the PBLs, the
same application name, and the same library list. - The debugging option on the Components properties
page in the Project painter is set to Component Is Debuggable. You
can also set the debugging option by checking the Supports Remote
Debugging checkbox in the Project wizard. - You have a client application that exercises the
methods and properties in the deployed components. This can be a
compiled executable built with any compatible development tool or
a PowerBuilder application running in another PowerBuilder session.
Starting the debugger
To begin debugging, open the application that contains the
deployed components. Click the Start Remote Debugging button in
the PainterBar and complete the connection information in the dialog
box that displays. Enter the login and password required for the
PowerBuilder remote debugging component, not for the deployed components.
Then select the components you want to debug.
You can only select components that were generated in PowerBuilder
with remote debugging support turned on. Remote debugging support
is a security setting that does not add any debugging information
to the component. You turn remote debugging support on when you
are testing a component, then turn it off when you deploy the component
to a user’s site to prevent users from stepping into and
examining your code.
Set breakpoints as you would when debugging a local application,
then start the client application that invokes the remote components
(if it is not already running).
Differences from local debugging
You will notice two major differences between debugging local
and remote applications:
- When you start the
debugger, it does not minimize. - The new Instances view shows each instance of the
components you are debugging. For each instance, it shows the component
and package names, an instance number, and its current state: running,
idle, or stopped. If there is more than one instance, a yellow arrow
indicates which one is currently being debugged.
About states
The instances view shows the state of each instance of each
component:
- Idle The component is idle or in the instance pool.
- Running The component is currently executing code.
- Stopped The component is stopped at a breakpoint waiting for a debugger
action.
When an instance is destroyed, it is removed from the Instances
view.
Multiple instances
Multiple component instances may be stopped at the same time,
but actions you take in the debugger only act on the first instance
that hit a breakpoint. This instance is indicated by a yellow arrow
in the Instances view. The current instance changes to the next
instance in the queue when the method completes or when you click
Continue.
You can also change context from one instance to another by
double-clicking the new instance in the Instances view. You may
want to do this if you step over a call to another component instance
and the Instances view shows that the called instance stopped.
Unsupported features The Objects In Memory view and expression evaluation are not
supported.