Didn’t we all wait for an easy way to debug the RTC? In NAV 2013 this is finally possible. This post won’t be to big, as most of the things can be mentioned pretty quickly.
Debugging can be started out of the development client by going to Tools – Debugger – Debug Session, of going to the session list in your Windows Client. You can select any (!) session to start debugging or click to debug the next session. Debug next session comes in handy when debugging Web services, NAS or background sessions. The debugger will open waiting for an error or a break point that was set.
You will see that the debugger is actually just a Page. This means it is fully customizable, all commands are also in code available now. The code overview in the debugger is a client add-in. This client add-in can resize text for bad seeing people among us.
Break points can be set from code, or from a debug session. The positioning of break points is also improved, since debugger now actually shows the real break point
One of the biggest annoyances in debugger is the number of times debugger comes through a certain break point. When debugging the posting of an invoice, you will press Next multiple times until you see that the line you want to debug is actually triggered. Well, no more of this, a break point can be conditional from now on. On top of your debugger you will see an action “Set/Clear Conditions”. In this screen you can put a condition which returns true or false to allow breaking only when you require it. The break point will look different in the code view to show that it is a conditional break point.
Let’s maybe run through all actions on top of the Page:
– Step Into: go further into your code, execute the next statement
– Step Over: go further into your code, but if it is a call to another function, … just execute without seeing all that code below
– Step Out: execute the rest of this function and stop on the next line of the calling function.
– Continue / Break / Stop: Speaks for itself I think
– Toggle: Toggle break points
– Set/Clear Conditions: as described before
– Break Rules: say when debugger needs to actually break:
=> Break on error
=> Break on record changes: let the debugger stop whenever a modify, insert, delete or rename happens
=> Skip CodeUnit 1: no more stopping on all CodeUnit 1 functions. (Yaay!)
– Disable All: leave all break points, but do not enable them.
– Break points: see where all break points are located, easily add, delete or disable/enable them.
– Variables: look at the values inside variables
– Last Error: show the last error again (could be from a previous debug session)
You can see there are a lot more possibilities now…
Let’s continue with variables. In older versions, we could not see the value of variables higher in the call stack, now we can see them, even in a watch. Adding watches became a little bit harder though, you first need to open the variables Pages and add a watch from there. There reason is that RTC does not support right clicking. However, hovering over a variable can show you the value of the variable.
Advanced Type variables such as DotNet only allow you to see if they are instantiated, not their internal values. If you do need to do that, you can still debug NST through Visual Studio as before. The code does not show the C/AL equivalent in comment anymore though…
Even though you debug only 1 session on the NST, keep in mind that locks still apply and that you could be blocking other users.
That’s about it. Hopefully you learned a few things you did not find out yourself yet.
*This post is locked for comments