Recently I had to debug some custom code I added in Dynamics NAV. Some object was throwing an error because of an overflow converting Text 60 to Text 30. Because in the code were the error occurred, many other objects were called, it was not so easy to see were the error originated from. But then I noticed a nice feature of the Dynamics NAV debugger that pointed me in the correct direction.

Let's make an example. Codeunit 365 is frequently used to format addresses when running reports. Let's say that when running a Sales Invoice something goes wrong when calling the FormatAddr function.

For example, someone has changed the table design of the Sales Invoice table and enlarged the 'Bill To Customer Name' from 50 to 100 characters. The FormatAddr function expects a parameter Name that can be maximum 90 characters in length. When printing an invoice for a customer with a name bigger than 90 characters this will result in an error.

Go to Tools and enable the debugger (Breakpoint on Triggers is not required for this example):

Then, run the report. You will notice that the debugger stops here (when the error is thrown):

The question now is, can we trace this back to the report and see via which objects and code the report called this function?

Yes, we can. In the debugger you have a special window for this:

The little yellow arrow shows you in what object you are debugging. BUT, here comes the great feature, you can double-click on the underlying objects, and then the debugger will jump to the code of that object.

The little Green arrow shows now where we are debugging, and you can directly see which code in what object was responsible for calling the FormatAddr function.

Even more usefull you can see the object number, name and the trigger/function…

And you can even go further back by double-clicking on the object(s) below this one!

How cool is that?

Comments

[popov]

vibe, cant you do this by selecting the Context

[popov]

vibe, you can inspect the variables on
lower call stack levels by selecting the 'Context' dropdown on the top of the locals window

[popov]

Wow!! you have found the "Call Stack". That's so great feature that ONLY Nav debugger has!!!

P.S.: Coming from MS Visual Studio This thing (the debugger) is full shit.

[vibe]

Rome wasn't build in a day :-).
Many things to say about the NAV debugger, but if you look back from where we came...there is progress in the debugging activity. Still not were we want to be but I am convinced that this will not be the last version of the debugger.

Anyway, it remains a good tip on how we can work with the current version of the debugger.

[Steffen Forkmann]

This is not a workaround - this is my daily horror.

Next point: You can't inspect variables on
lower call stack levels and even worse there is no "step out" feature in the navision debugger.

You have to set a breakpoint on the last line of the actual function and hit F5 and the Ctrl+F8.

[Steven]

Yes, that is correct, when looking at the call stack with the Nav debugger it does not allow to set breakpoint there.
But as a workaround, you can see the object & trigger & code were you want the breakpoint and so close the debugger, open the object, set the breakpoint and start debugging again.

I agree, this is open for improvement ;-)

[Steffen Forkmann]

Sorry, but the Navision-Debugger has only a very very poor implementation of the call stack. Have you ever tried to add a breakpoint outside the actual object?

[rashed]

This a good graphical easy way to show how to use the debugger.
There is a tips and tricks on mibuso on this as well.

http://www.mibuso.com/forum/viewtopic.php?t=21979