The debugging process is for many people one of the most tedious tasks a developer has to do.
Depending on the complexity of the process you are trying to debug, this action can take from a few seconds to a few hours. A few hours of seeing the same lines of code over and over…
If we add to that the fact that some processes are loops and the same code is repeating itself when you only need one of the iterations (the processing of the sales lines when posting the invoice for example), the end result is a very time consuming course of action to follow.
As developers we are often faced with the choice: going with your gut or doing the due diligence and completely debugging the malfunction.
Microsoft knows this and when they can, they add some goodies to help us out as well as heping customers! This is one of them
Ever since we transitioned to the first full RTC version of NAV (NAV 2013) a new debugger was included. It contains a lot of the functions the previous debugger had, and some new stuff!
One of the things is the support for conditional breakpoints.
But hold on a second… What is a breakpoint?
A breakpoint is a tool for debugging. It basically marks a place or a line on your code and tells the debugger where it needs to stop in case the execution of the bussiness logic leads it there. As you know Dynamics NAV has thousands and thousands of lines of code, so following every line when you need only to see a specific spot is just an overkill. A breakpoint helps with that.
So why do we need a conditional breakpoint?
Imagine you have a customer that says there is an issue when creating a warehouse pick coming from 30 different sales orders. Each sales order with its own 50 lines of different items. And the issue apparently only happens when the system works with one specific item. You can imagine how setting a breakpoint where the system checks for the item will easily make you have to check all the items of all the orders until you find the one you want. Like I said, very time consuming…
A conditional breakpoint helps with that issue. You can tell the system to stop when checking the item, but only the item with the No. “XYZ001″. Now the debugger will only stop once, and will stop with the item that is causing the problem.
Nice, isn’t it?
What do we need to know when working with conditional debuggers?
Since there are many different datatypes, some of them are very specific and are not that “debuggable”. Like Automation for instance The datatypes supported are:
And also you should know that a conditional breakpoint will break the execution of your code if the condition is true. Which means there needs to be a condition To accomplish this you can use the following operators:
Ok, I understand the theory. How do I use them?
It’s rather simple, you’ll see
What you need to do is set your breakpoint like you normally would, execute your code with the debugger open and reach the breakpoint.
In my case and just to show a simple example, I have set a breakpoint on the OnValidate for the Payment Method Code on the Customer table, like so:
So I open the debugger, debug my session and go to the RTC client and change the Payment Method Code. Doing this causes the debugger to stop the execution like so:
I have noticed than emptying the Payment Method Code causes the debugger to also stop the execution, and I do not want that. I only want to see that code when the value of Payment Method code is NOT empty. In order to accomplish this, I stay on that breakpoint and find the “Set/Clear Condition” button and write the condition I wish. In my case:
So by doing this I managed to have the debugger stop only when that field has value, and not when it’s being emptied! Awesome 😀
A couple of things I would like Microsoft to add is the option of adding conditional breakpoint from within the development environment, and some sort of “Field Menu” for the “Debugger Breakpoint Condition” window. Right now you must type it manually which can lead to typos. Regardless, it is very nice to have this option.
I know it’s been a while since this feature was released but if one person has learned about conditional breakpoints from this post then it’s worth it