When the debugger stops the execution of the program flow, you have four options to continue the execution. You can find those options on the ribbon pane of the Debugger page, as shown in the following screenshot:
The following is a description of each of the options available to continue execution:
Let's see an example of each execution mode: the insertion of a new record on the Bank Account
table. We will use the same example for all the four options.
The Step Into execution starts with the first statement of the
OnInsert
trigger of the Bank Account
table. The yellow arrow (shown in the following screenshot) shows the line that is currently going to be executed:
If you press F11 (Step Into) repeatedly, you will see how each statement is executed. Four statements later we find a function call. The debugger then stops on the first statement of the InitSeries
function. A few statements later, we find a new function call, and the debugger goes to the first statement of the GetNextNo
function.
Using these options, the debugger stops on each and every single statement. If you keep on debugging this example, you will see that after pressing F11 a few hundred times and visiting numerous functions and triggers, the new bank account will get inserted.
For a person who wishes to learn the ins and outs of how to develop in Dynamics NAV, going through this process will give you a good sense of what code is run at what time. Many developers learned how the application worked when they started out in NAV development.
Try to avoid this option unless you don't know what you are looking for and you have no other option than executing all the statements one by one, especially for long transactions.
In the last section, we used the Step Into option until we reached the first statement of the GetNextNo
function. We will continue debugging from that point, but using the Step Over option, as shown in the following screenshot:
If you press F10 a few times, you will see that the debugger stops on each statement, just as the Step Into option does.
The seventh statement of the function is a call to the SetNoSeriesLineFilter
function. If you use the Step Over option on that statement, the debugger will execute all the code inside the function without stopping and will stop on the first statement after the function call, that is, the next statement in the current function.
Use this option when you already know the code that executes inside the function and you know that the function that is going to be called does not contain the bug you are looking for.
In the last section, we used the Step Over option until we reached the first statement after the SetNoSeriesLineFilter
function call, which is the GetNextNo
function. We will continue debugging from that point, but using the Step Out option. Please refer to the following screenshot before proceeding:
The Step Out option executes all the statements in the current function, and stops on the first statement of the calling function.
We are now on the GetNextNo
function that was called from the InitSeries
function, as we have seen in the The Step Into option section. If you click on the Step Out option, the debugger will execute all the remaining statements in the GetNextNo
function, including the statements inside the new function call. After that, the debugger will stop on the next statement of the calling function, the InitSeries
function.
Use this option if you have stepped inside a function to see its code and variables but, once inside the function, you have realized that the bug you are looking for is not there.
In the last section, we used the Step Out option until we reached the next statement after the call of the GetNextNo
function. We will continue debugging the code from that point, but using the Continue option.
With the Continue option, the execution of the code continues until:
Now, click on the Continue option in our example and see what happens.
In the Code part of the debugger, we keep seeing the code we had before the Continue option was clicked. But the yellow arrow that showed us the current line is not there anymore. At the top of the preceding screenshot, we can read that the debugger is now waiting for a break.
The execution of the code has continued, a new bank account has been created, the user gets back the control of the execution, and the debugger is waiting for a new breakpoint.
You can use this option if you don't need to follow the code line by line and want to wait for a breakpoint instead. You also can use this option if an error occurs on a process and you want to know where the error has occurred. In this case, you can turn on the debugger, reproduce the process that is causing the problem, and use the Continue option to let the debugger find the line causing the error. Of course, you will need the Break On Error option enabled. You can read the Break Rules section for more information about this option.