You can use the F9 key to toggle between breakpoint settings, enable or disable commands and remove breakpoints in the C/AL Editor. You can also select Tools, and then Debugger, and then the Toggle Breakpoints menu command. Information about the breakpoints is stored in the Breakpoints virtual table when you close the C/AL Editor.

The Breakpoints Virtual Table

The Breakpoints virtual table (ID 2000000059), can store information about the breakpoints that you set. The following table lists the fields in the Breakpoint virtual table.

Field Description

Object ID

The ID of the object for which breakpoint information has been stored.

Object Type

The table, form, page, report, dataport, or codeunit.

Trigger Line

The number of the trigger line where there is a breakpoint.

Code No.

A code number for the trigger that contains a breakpoint. This number is used to identify the trigger at run-time.

Trigger Name

The name of the trigger where there is a breakpoint.

Object Name

The name of the object.

Enabled

A check mark indicates whether the breakpoint is enabled.

You must create a tabular form based on the Breakpoints virtual table to manage breakpoints. Information about breakpoints is saved when you close an object or when you save a new object—compilation is not needed. Breakpoints are not stored for objects that you do not save.

Storing Breakpoints in an XML File

Breakpoints that are stored in the Breakpoints virtual table are automatically stored in a NaviBP.xml file. By default, this file is located in the same folder as the fin.zup file. On a Windows XP computer, the path is: C:\Documents and Settings\user\Application Data.

The following is an example of an XML file that contains breakpoint information for two objects.

<?xml version="1.0" ?>

<BreakpointList>

<Object Type="Codeunit" ID="2" Name="MyCodeunit1"

<Object Type="Codeunit" ID="3" Name="MyCodeunit2"

</BreakpointList>

This file contains breakpoints for MyCodeunit 1 and MyCodeunit 2. The objects are shown as XML elements. called "Object". The object element has three attributes: Type, ID, and Name.

If you expand the first object, MyCodeunit 1, you can see one "Breakpoint" element. This shows that the object contains one breakpoint.

<?xml version="1.0" ?>

<BreakpointList>

<Object Type="Codeunit" ID="2" Name="MyCodeunit1">

<Breakpoint>

<TriggerName>OnRun</TriggerName>

<CodeNo>6</CodeNo>

<TriggerLine>12</TriggerLine>

<Enabled>No</Enabled>

</Breakpoint>

</Object>

<Object Type="Codeunit" ID="3" Name="MyCodeunit2"

</BreakpointList>

When a breakpoint element is expanded, you can see the following types of information for the breakpoint.

XML tag Description

TriggerName

The name of the trigger that contains the breakpoint.

CodeNo

The code number for a specific trigger in an object. This number is used to identify the trigger at run-time.

TriggerLine

The number of the line in the trigger where the breakpoint has been defined.

Enabled

A Boolean expression to determine whether the breakpoint is enabled.

Starting Microsoft Dynamics NAV or Classic Application Server Using Another Breakpoint File

You can start both Microsoft Dynamics NAV and Classic Application Server with a breakpoint parameter. This enables you to specify a particular file for saving and loading breakpoints, for example: FIN.EXE breakpoints=C:\MyBreakpoints.xml.

Storing Debugging Information in the FIN.ZUP File

The selections that you make in the menu commands are stored in the fin.zup file. This means, for example, that if the debugger was active and set to break on triggers when you logged off, these selections will apply when you log on again.

See Also