This document lists the Debugger current known limitations:
When a modal dialog is open in the active DOORS client, it may happen that DOORS does not execute the DXL code it is instructed to run by DXL Editor. In this case, the debugger cannot suspend on a breakpoint as the DXL file is not executed at all, without DOORS informing DXL Editor about it. Note that not all DOORS modal dialogs produce this unexpected behavior. Still, recommendation is to close dialogs in DOORS by the time you request DXL Editor to run or debug a DXL file.
There are some variable patterns that are not handled at this time by the debugger.
For such patterns, the corresponding variables won't be visible in the Variables view.
Note however that it does not impact the debugger execution.
Unhandled variables patterns:
i = 5;
You may declare variables in your DXL code without yet assigning a value to the variable.
Early DOORS 64-bit client versions do not offer any reliable mean to detect whether a variable is unassigned.
Here is the compatibility matrix on this topic:
|DOORS client||Architecture||Unassigned variables correctly detected?|
|188.8.131.52 and earlier||64-bit||
If a variable is unassigned, the debugger will likely show
As a workaround, you are recommended to assign a value (e.g.
|184.108.40.206 and newer||64-bit||Yes.|
There are some DXL code locations that the debugger won't access. You won't be able to install breakpoints and to step into such locations.
includestatements and resolve them to absolute file paths (see Debugger Architecture). However if you override the Addins paths in the DOORS command line (using
-layoutaddins), the DXL Debugger won't be aware of these new locations. In that case you won't be able to step into functions defined in those locations.
show(DB)function is redefined to call
block(DB). Without doing this, the debugger would consider the execution is terminated when a dialog box is displayed, and you would not be able to debug code invoked by dialog callbacks.
destroy(DB)should not be called from a callback. This is particularly true when using
block(DB), which is what the debugger does (see previous item). Calling
destroy(DB)from a callback can lead to platform unstability.
There are some limitations in the display of stack frames and DXL variables:
Skip. This is because the debugger has no information on the type of keys and of values of this
Skip. Trying to display the
Skipcontent without such information can result in DOORS crashing.
Array. This is because the debugger has no information on the type of content within the
Array. Trying to display the
Arraycontent without such information can result in DOORS crashing.
f2()is called in a
returnstatement of a function
f1(), suspending the execution inside
f2()will not show
f1()in the execution stack frames.
There are some limitations in the type of expressions you can evaluate when the execution is suspended.
The DXL Debugger cannot be used to debug Layout DXL scripts, as such script requires a current Object to be pre-selected by DOORS.
The DXL Debugger cannot be used to debug Triggers DXL scripts, as such script requires a trigger event to be pre-selected by DOORS.