The NetMan Debugger is a tool you can use to check your Scripts both simply and in great detail. This chapter provides details on operation of the Debugger as well as an example of Script testing with this tool.
Run the Debugger in the Script Editor by selecting clicking on Debug in the Ribbon. The currently selected Script is loaded in the main Debugger window:
The main window has the following panes and operating elements:
A. Program menu. Contains commands for running program functions and helper programs, such as the Environment Monitor.
B. Ribbon. All program functions are available in the Ribbon, at the top of this window.
C. Script window. The Script window shows the sequence of actions contained in the Script.
D. Trace messages. This window shows the trace messages on each processing step.
E. Environment window. This window shows the environment variables in the Script.
The following functions are available in the Ribbon:
NetMan Tools. Opens the NetMan Tools.
Script Editor. Opens the Script in the Script Editor.
Start. Begins the Script sequence. The Script runs from beginning to end.
Step. Runs the next processing step in the action sequence. The Script is paused after the step executes. Use this function to execute a Script step by step.
Restart. Resets the action sequence.
Test. Starts the test mode. Use the test mode to test the Script sequence without modifying any files or writing registry entries.
Stop. Stops the Script sequence.
Set. Activates all break points.
Remove. Removes all break points.
Environment. Shows the Environment window.
Trace messages. Shows the trace messages.
Script window
The Script window shows the individual processing steps in the action sequence. The actions are listed in the order in which they are processed, going from top to bottom. The checkbox before each action step lets you activate a break point for that step. When a break point is active, the action sequence is stopped at that point. The column between break points and actions shows symbols during processing to indicate whether a processing step was successfully executed (green checkmark) or not (exclamation point). The Action column shows the processing step number and the name of the action. The three symbol columns after the Action show the following:
This action is designated for execution.
This action is executed using a System account.
Conditions have been set in this action for 'execute' permission.
The Return values column shows the return values from each processing step. The Description column shows the description, if one has been entered for the action.
Trace messages
The trace messages window shows trace messages from the system regarding the selected processing step. You can see at a glance which errors occur at which processing steps.
Environment window
The Environment window shows all variables that the Script writes in the environment.
Example: Using the NetMan Debugger to check a Script
In this example we use a Script that connects both a network drive containing user data and a network printer for use with a specific program. When the program is closed, these network resources are disconnected again. Furthermore, a Conditional Label is integrated for error control. We start the NetMan Debugger by clicking on Debug in the ribbon. In the Debugger program, we click on Step in the ribbon to run the first processing step:
An error occurs in this first step, as indicated by the exclamation point. We look at the trace messages:
The # column shows that the error is recorded in the trace messages from the first action. We see that the Connect Drive action failed, and that the operating system reported Error 67, "The network name cannot be found." The trace messages also show the basic processing logic of NetMan Desktop Manager: When an action produces an error, Script processing is canceled. If we define a return value variable for error response, however, the output is modified as follows:
Connection of the network drive fails, but because a return value variable has been defined, a value of 0 for "Error" is written in that variable and Script processing continues. In our example, this means that the Script jumps to Action 6, Conditional Label, which handles the error. As a rule, if a return value variable has been defined, then NetMan Desktop Manager does not cancel Script processing because it "expects" the problem to be handled with the subsequent analysis of the return value.
The error in our example is caused by a typographical error in the USERNAME system variable:
As seen in the outlined area, the string as it was entered in the input field (variables are coded) is shown on the left, while the plain text output is shown on the right. Looking at the output, we see that the USERNAME variable was not interpreted; this is because it was not named correctly in the input field. We correct the variable and the action is executed correctly:
Compared to typos, however, errors in the processing logic can be quite difficult to detect. We click on Start in the ribbon menu to run the entire Script:
The yellow checkmark at step 3 above indicates that the action was processed, but not executed. The action was assigned a permission, which in turn is based on "Condition (Variable) printer=0". Because the value returned in the printer variable in this step is 1 (see the second processing step), this action is processed, and then skipped rather than executed. When Action 7 is processed, a critical error occurs that causes the script processing to halt. As we can see in the Script window at line 7 (drive=0), the condition required for execution of the action is not met. We refer to the trace messages for details:
The Conditional Label action defines what happens in case of error; that is, if the return value in the userdrive value is "0" (meaning the network drive could not be connected). In this case, the error message defined in Action 8 is displayed and Script processing is terminated without connecting the network printer or launching the program. The second line of the trace messages shows that no permission was defined for the action, which means it will definitely be executed when Script processing reaches that point. The Script would function in this form, because Script processing stops and none of the subsequent actions are executed. The correct solution to the problem, however, would be to define a permission for the Conditional Label and subsequent actions with "Permission (Variable) drive=0", to ensure that they are only executed in the event of error. We correct the script in the example accordingly, and the script can now be processed to the end without errors:
