Traditional Debugging

Debugging refers to finding and fixing bugs such as abnormal operations or logic errors in the application program. Due to the nature of development that cannot produce perfect results from the beginning, the debugging process continues from the beginning to the end.

The easiest debugging method for developers to use is to display objects or variables that need to be checked on the screen. The record left in the output window is called log, and you can use the trace method in Nexacro. trace, as per its meaning or tracing, is the function of logging so that the developer can trace the flow of logic or the value of variables. If described in text format as follows, information is output in the Output window and log file.

The alert method is used as much as the trace in the development process. Trace involve the hassle of having to find and check the part that it needs in the left log, but it has the advantage of being convenient because the alert is opened as pop-ups on the screen and only necessary results can be checked.

trace and alert have the advantage of being easy to use, but if the project consists of many files or if the code is long and complex, then they make debugging more complicated. Also, when outputting information on multiple variables or objects, there are many space limitations and it is inconvenient to check the information. Furthermore, you have to manually code with the script, and after debugging, the developer has to delete it directly, which may cause new problems in the process.

In Nexacro Studio, its own debug function is included to help developers debug more efficiently. This chapter describes the debug functions provided in Nexacro Studio and how to use them.

Debugging with Debug Functions

The trace and alert methods described above are easy to use but have limitations in checking the flow of the process or the object containing a lot of information. Also, it is difficult to clearly understand what is wrong with the current code. However, using the debug function makes it easier to keep track of specific information, such as where the problem came from and through what path.

The debug function of Nexacro Studio consists of the menu and the toolbar where you can execute commands, and the debug information window where you can view information such as objects, functions, and logs.

Debug Menu & Toolbar

In the debug menu and toolbar of Nexacro Studio, you can use the commands necessary for debugging. The configuration of the debug menu and toolbar is the same, except for commands related to the conditional breakpoint.

The main debug commands support shortcut keys. In actual debugging, it is much more effective in terms of speed to use shortcut keys rather than selecting debug commands from the menu or toolbar.

Debug Information Window

Using Debug Functions

Running/Ending Application in Debugging Mode

Debugging mode provides the environment in which errors in the application can be traced and resolved by using the debug function as the execution form of the application for debugging.

Debugging mode can be executed by selecting [Start Debugging] or [Start Form Debugging] from the Debug menu. [Start Debugging] is used when executing the entire project and [Start Form Debugging] is used to execute only the currently open form.

To end debugging mode, select [Stop Debugging] from the Debug menu.

Adding/Deleting Breakpoints

Breakpoints are used to specify where to pause in debugging mode. This specified location can be found in the script editing window and the Breakpoints window. In the script editing window, a marker is stamped next to the line number on the left side of the code, so you can check the setting status of the breakpoint. In the Breakpoints window, breakpoints are displayed in the form of the list, and double-clicking on them allows you to move to the source location where the breakpoint is marked.

Once you specify the breakpoint, it remains there until the user deletes it, even when Nexacro Studio is ended.

When you specify the breakpoint, a marker is added before the line and the breakpoint information is registered in the Breakpoints window. Also, once the breakpoint is specified, it remains as-is until the user deletes it, even when Nexacro Studio is ended.

Here is an example of how to add/delete breakpoints.

Adding/Deleting Conditional Breakpoints

The user can set the breakpoint to only hit specific conditions as needed. Breakpoints in which conditions are set in this way are called conditional breakpoints.

If you set the conditional expression, then the breakpoint is only hit when the set condition is met when the application execution reaches that line. If you set the number of ignores, then the breakpoint is ignored even when the code execution reaches that line, and hits are made after the number of times you set is exceeded.

The basic usage of conditional breakpoints is the same as breakpoints, except that you can set Conditional Expressions and Numbers of Ignore.

Here is an example of how to add/delete conditional breakpoints.

When the input is completed, you will see the orange marker next to the line number, and you can check the setting information in the Breakpoints window as follows.

Enabling/Disabling Breakpoints

The specified breakpoints can be set to be enabled or disabled as needed. This function can be used to temporarily disable the breakpoint for the next time you need to use it again.

When you enable or disable the breakpoint, the marker of the line and the breakpoint information in the Breakpoints window are changed according to the state.

Here is an example of how to enable/disable breakpoints.

Executing Code in Debugging Mode (Continue)

To continue executing code in debugging mode, use the Continue command. Running Continue will execute the code between the current breakpoint and the next breakpoint and then stops at the next breakpoint.

Here is an example of how to execute the code with the Continue command.

Executing Code with Step Command (Step Into, Step Over, Step Out)

When using breakpoints, it is good to use them only where you need them. When debugging the application with long and complex code, if you overuse breakpoints too much, then the execution efficiency will decrease because the user must manually enter the Continue command the number of times the breakpoints are specified. Therefore, if you execute the code line by line in a specific part and need debugging, then it is convenient to use the Step command.

The Step command functions as a temporary breakpoint. In other words, it can be used when debugging by stopping application execution in the location where you do not specify the breakpoint. The Step command is divided into Step Into, Step Over, and Step Out according to the operation method.

The following is an example sample that receives two numbers from the user and outputs the result of adding them. The btn_calc_onclick function is the event function that occurs through a button click, and it is assumed that the function is called when the user inputs the numbers 17 and 2 and clicks the operation button.

The following is an example sample that receives two numbers from the user and outputs the result of adding them. How to run the code with the Step command is shown with this example.

How to Use Step Into

Execute the code line by line. When encountering the function call, move inside the corresponding function and execute the code line by line.

How to Use Step Over

Execute the code line by line. When encountering the function call, do not move inside the corresponding function, execute the function, and move to the next line.

How to Use Step Out

Execute the rest of the code in the currently executing function, return to where the function was called, move to the next line, and stop.

Step Out is used with Step Into rather than independently. It performs Step Into and is used to skip debugging in the function when you do not need to look at it anymore while performing the code by moving to the inside of the function.

Executing Code at Once to Cursor Location (Run to Cursor)

Stop after executing code from the currently hit breakpoint to the cursor location. If there is another breakpoint between the current breakpoint and the cursor, then execution stops at that breakpoint. Also, if the cursor location is the location that cannot be reached on a branch, then it stops after executing to the next breakpoint.

Here is an example of how to execute the code with the Run to Cursor command.

Checking Variable Value (Variables)

The most basic of debugging is checking the value of the object or variable. This information can be found in the Variables window.

Variables display the value of the object or variable that is accessible from where the breakpoint is hit. For objects containing members, you can expand or collapse the details with the +/- button in the list. Items with changed values are displayed in bold red. Variables operate automatically when debugging mode is enabled.

Here is an example of how to check variable value with Variables.

Checking Variable Value (Script Editor)

The script editor provides Assist Tip and Inline Assist Variable functions to intuitively check object/variable values during debugging.

Assist Tip is the function that displays the information in a pop-up form when you place the mouse cursor over the object or variable for which you want to check the value in the script editor. If the item is the variable, then only the value is displayed, and if it is the object, then the members and the values are displayed in the tree format.

Inline Assist Variable is the function that displays the values of all objects and variables existing between the function declaration part and the currently hit breakpoint next to each line in the script editor. In addition, not only the function to which the hit breakpoint belongs, but also the function on the Call Stack associated with it displays the object and variable values before the function is called.

Here is an example of how to check the variable value in the script editor.

Observing Changes in Variable Value (Watch)

You can register a specific object or variable in Watch and observe the change in its value while debugging is in progress. Items with changed values are displayed in bold red.

Once the object/variable is registered to Watch, the list will remain until the user deletes it, even if Nexacro Studio is ended.

Here is an example of how to observe variable value with Watch.

You can also add it from the script editor. First, drag and drop the object name or variable name to select it, then drag and drop it on the Watch window, or right-click and select [Add Text to Watch] from the context menu.

Checking Function Call Information (Call Stack)

When debugging complex code with a mixture of objects and functions, it is important to understand the relationships between functions. If you can understand at a glance which function the code you are looking at exists, in which function it is being called from, etc., then it is very helpful to understand the flow.

Call Stack provides the function call history, allowing you to check the call relationships between functions. Functions called up to the current location are displayed in reverse order. If you double-click the function name of the item, then you can move to the code of the called location.

Call Stack operates automatically when debugging mode is executed, and function call information is updated according to the flow of code execution.

Here is an example of how to check function call information.

The fn_add function, which is the current location, is located at the top, followed by the btn_calc_onclick function that called the fn_add function. You can also see several functions below it, and these are functions used inside Nexacro, so you do not need to worry about them unless in special cases.