Microsoft Dynamics NAV: Diagnosing Code Problems

0
90
6 min read

 

Microsoft Dynamics NAV 2009 Programming Cookbook

Microsoft Dynamics NAV 2009 Programming Cookbook

Build better business applications with NAV

        Read more about this book      

(For more resources on Microsoft Dynamics, see here.)

Introduction

No one writes perfect code on their first attempt. When running hundreds or even thousands of lines of code at a time, it can be extremely difficult to determine exactly where an error occurred and what caused it. That’s why we have tools like the Debugger, Code Coverage, and Client Monitor in Microsoft Dynamics NAV.

For the most part the recipes in this article will not deal with writing your own code or writing better code. Instead we will focus more on how you can determine what is happening with code you have already written.

Using the debugger

This recipe will show you how to use the debugger to examine the code that is currently executing. We will demonstrate how to go through the code line-by-line and watch how values and objects change.

How to do it…

  1. Create a new codeunit from Object Designer.
  2. Add the following global variable:

    Microsoft Dynamics NAV: Diagnosing Code Problems

  3. Add the following global text constant:

    Microsoft Dynamics NAV: Diagnosing Code Problems

  4. Add a global function called ChangeCustomerName.
  5. The function should take in the following parameter:

    Microsoft Dynamics NAV: Diagnosing Code Problems

  6. Add the following code to the function:

    Customer.Name := NewName;

  7. Add the following code to the OnRun trigger:

    Customer.FINDFIRST;
    ChangeCustomerName(Text001);
    Customer.VALIDATE("Post Code");

  8. Save and close the codeunit.
  9. From the Tools menu in the NAV client select Debugger | Active (Shift + Ctrl + F11).
  10. From the Tools menu in the NAV client select Debugger | Breakpoint on Triggers (Shift + Ctrl + F12).
  11. Run the codeunit.

How it works…

When you run the codeunit, the Microsoft Dynamics NAV Debugger window will appear just like the one shown in the following screenshot:

(Move the mouse over the image to enlarge it.)

Before we get into the details of this window, we need to understand what caused it to appear. Setting the debugger to Active from the Tools | Debugger menu means that the debugger window will open every time the system encounters an error. In this case, though, we know our code doesn’t produce any errors. We want to look at it anyway so we turn on the Breakpoint on Triggers option as well.

There are five components to the debugger window. The first is the menu and toolbar at the very top. They function just like any other toolbars you’ve seen. You can mouse over each button to get a tool tip of what it does.

The second component sits right below and contains the actual code from the current object. Here you can see a small yellow arrow pointing to the first line of our codeunit in the OnRun trigger. This is the line that is about to execute. Note that it has NOT executed yet. We’ll explore each of the other three components as we move through our code.

Use the F8 key or click on the Step Into button on the toolbar. The window will now look like the one shown in following screenshot:

(Move the mouse over the image to enlarge it.)

The yellow arrow has moved to the second line of code and the first line has executed. Notice the red text in the bottom left-hand corner. This is the Variables window (bottom left window). It lists all the variables and their values from the current object. At first, our customer variable was uninitialized because we had not executed the Customer.FINDFIRST line. That line retrieved a record from the database causing the value of the variable to change. This text will only remain red until you take another step into the program.

The next line of code that will execute is:

ChangeCustomerName(Text001);

What is this Text001 variable? If you’re unsure of the value of a text constant, or you don’t want to scroll through a possibly long list of variables in the Context window, you can add a shortcut to the Watch List (bottom right window). Right-click on Text001 and go to Add Watch. The variable will be added to the Watch List along with its current value. Go ahead and hit F8 to step into the next line.

(Move the mouse over the image to enlarge it.)

The yellow arrow jumps to the function that we just called. That brings us to our last window, the Call Stack (bottom middle window). It is important to know how you got to the code you are currently viewing. By looking at the Call Stack you can see that we were in the OnRun trigger of the codeunit and then jumped to the ChangeCustomerName function. You can click on each level of the stack to see the code for that object.

(Move the mouse over the image to enlarge it.)

You may not always want to go through your code line-by-line, though. Try hitting the F5 key or the Go command from the Debug menu. This will cause you to jump to the next function which is called instead of the next line. You will find yourself in a complete new object, the Customer table. Notice how the Context menu completely changes because the old variables are no longer in scope. They do not belong to the current object being examined.

There’s more…

One common annoyance is trying to stop the debugger. You will find yourself in the middle of debugging your code and have that “Aha! I know what’s wrong!” moment. You will click on the “X” to close the window only to have the debugger pop right back up at you.

From the Debug menu click on Stop Debugging (Shift + F5). This will stop the debugger until you turn it on again and, more importantly, allow you to continue with your development. Stop Debugging also performs a rollback of the changes that have happened to the database since you started the debugger.

Setting breakpoints

Stepping through code line-by-line or function-by-function can take forever. Luckily there is an easy way to tell the debugger to stop right where we want it to.

How to do it…

  1. Create and save the same codeunit discussed in the Using the debugger recipe in this article.
  2. Design the codeunit.
  3. Go to the following line of code in the OnRun trigger:

    ChangeCustomerName(Text001);

  4. Press F9 twice.
  5. Go to the following line of code in the OnRun trigger:

    VALIDATE("Post Code");

  6. Press F9 once.
  7. Your window should look like the following screenshot:

    Microsoft Dynamics NAV: Diagnosing Code Problems

  8. Save and close the codeunit.
  9. From the Tools menu in the NAV client select Debugger | Active (Shift + Ctrl + F11).
  10. Run the codeunit.

How it works…

When running the debugger on this codeunit, it should stop on Customer.VALIDATE(“Post Code”) line of code. This is because we have set a breakpoint here, which was the filledin red circle at the left of that line. The debugger stops right where we tell it to, that is right before that line of code executes.

You will notice another mark. It is a red circle that is not filled. This is used to mark old breakpoints that you are not currently using. This is useful when you are trying to debug large amounts of code and want to temporarily remove a breakpoint or remember where you had one.

There’s more…

The debugger is not perfect by any means. Some might even say it has a mind of its own sometimes. It doesn’t always stop exactly where you want it to. It is common practice to set a breakpoint on a few successive lines of code in order to ensure that you stop in the general area.

LEAVE A REPLY

Please enter your comment!
Please enter your name here