New Debugger features in AX7

This section provides information about the new features that we’ve added to the debugging experience in Visual Studio.

Adding ToString methods to your classes

It’s often a benefit to add ToString() methods to your classes. The effort spent doing this comes back many times and it’s easy to do. This advice also holds true for legacy X++.
Note: Since ToString methods can be called at unpredictable times, it isn’t a good idea to change the state of the object here.

Identifying unselected fields

It’s a common source of bugs to use fields from a table when these fields don’t appear in the field list in a select statement. Such fields will have a default value according to their type. It’s now possible in the debugger to see if a value has been selected or not.

Exercise

Consider the following code:

class MyClass
{
  public static void Main(Args a)
  {
    FMRental rental;

    select EndMileage, RentalId from rental;

    rental.Comments = "Something";
  }
}

Set a breakpoint on the assignment statement. Make your class the startup object in your project, and start by pressing F5.

When the breakpoint is encountered, view the rental variable by expanding it in the locals window. You’ll see something similar to the following graphic.

You can see that the fields that have been selected (EndMileage and RentalId) appear with their selected values, while the unselected fields appear as null. This signifies their value wasn’t fetched from the database. Obviously, this is a debugging artifact. The values of the unselected fields will be the default value for the type of the field.
Step over this and notice how the debugger changes the rendering to the actual value.
Note: If the table is set to Cache, the system will always fetch all fields from the entire table, irrespective of the field list provided in the code.

The Auto and Infolog Windows

The debugger will allow you to easily access certain parts of the state of the application easily. This information is available in the autos window, where the current company, the partition, the transaction level, and the current user id are listed.

There is also a window showing the data that is written to the Infolog.

New breakpoint features

The Visual Studio debugger supports conditional breakpoints and breakpoints that are triggered by hit count. You can also have the system perform specific actions for you as you hit the breakpoint. None of these features were available in the legacy debugger. These are explained below:

• Hit count enables you to determine how many times the breakpoint is hit before the debugger breaks execution. By default, the debugger breaks execution every time that the breakpoint is hit. You can set a hit count to tell the debugger to break every 2 times the breakpoint is hit, or every 10 times, or every 512 times, or any other number you choose. Hit counts can be useful because some bugs don’t appear the first time your program executes a loop, calls a function, or accesses a variable. Sometimes, the bug might not appear until the 100th or the 1000th iteration. To debug such a problem, you can set a breakpoint with a hit count of 100 or 1000.
• Condition is an expression that determines whether the breakpoint is hit or skipped. When the debugger reaches the breakpoint, it’ll evaluate the condition. The breakpoint will be hit only if the condition is satisfied. You can use a condition with a location breakpoint to stop at a specified location only when a certain condition is true.
  For example, suppose you’re debugging a banking program where the account balance is never allowed to go below zero. You might set breakpoints at certain locations in the code and attach a condition such as balance < 0 to each one. When you run the program, execution will break at those locations only when the balance is less than zero. You can examine variables and program state at the first breakpoint location, and then continue execution to the second breakpoint location, and so on.
• Action specifies something that should occur when the breakpoint is hit. By default, the debugger breaks execution, but you can choose to print a message or run a Visual Studio macro instead. If you decide to print a message instead of breaking, the breakpoint has an effect very similar to a Trace statement. This method of using breakpoints is called tracepoints

Exercise

Consider the following code:

class PVsClass
{
  public static void Main(Args a)
  {
    int i;
    for (i = 0; i < 10; i++)
    {
      print i;
    }
  }
}

Put a breakpoint on the print statements by pressing F9 while that statement is selected. This will create a normal, unconditional breakpoint. Now, use the mouse to open the context menu for the breakpoint and select Condition. Put in a condition that indicates that the breakpoint should happen when the value of the ‘i’ variable exceeds 5. Set the class as a startup project, and the class containing the code as the startup item in the project. Run the code. Feel free to modify the value of ‘i’ using the debugger.
Now, remove this breakpoint, and use the Hit count feature to accomplish the same thing.
Note: A breakpoint can have several conditions. It’s often helpful to hover the cursor over the breakpoint, causing an informative tooltip to appear.
Tracepoints are often useful tot race execution. Insert a tracepoint on the line in question and log the value of the variable. The trace output will appear in the output window in the debugger.