Overview:

The information in this article applies to: NXC-M, NXC-ME, NXC-MPE, NXC-ME260, NetLinx Studio

Symptoms

Debug Breakpoints seem to have line number problems - breakpoints are often invalidated. When stepping through code, the debugger seems to stop in strange places.

Cause

For Debug Breakpoints to work correctly, you must have C/C++ style statement terminators (semicolons) at the end of your statements. Otherwise what the debugger thinks is a statement end won't match with what you think is a statement end, and strange line number anomalies will occur.

Resolution

Unfortunately, there's no real documentation on exactly where to put semicolons in every case - even for C/C++programmers. They learn because the compiler will usually generate errors if they don't put the semicolons in the right place. The one and only place NetLinx requires the semicolon is in a FOR loop declaration:

FOR (<initial statement>; <condition statement>; <after pass>) { }

Other than this, NetLinx compiler will NOT generate an error if you don't have semicolons, which makes NetLinx easier to learn for Axcess programmers, but harder to guess where to put statement terminators.

• You don't need or want a semicolon at the end of expressions; like IFs, WHILEs, etc.
• You don't need a semicolon after an include, because they should be in the appropriate places in the include file.
• You don't need a semicolon after braces { or }.
• You don't need a semicolon after section names DEFINE_DEVICE, DEFINE_EVENT, etc.
• For Debug Breakpoints to work correctly, you need semicolons at the end of most other statements.

So if you know you're going to want to debug a program using breakpoints, add semicolons to the end of statements where you think appropriate. A small example program is attached.

500-DL1-Semicolon Example.zip