Breakpoints in include file

Same for me.

>

>

As a workaround I'm inserting the DEBUGGER:SET-BREAK (). method in the

include and compile all .p files using that include.

I wasn't aware that it worked in earlier releases. So it sounds like a

bug.

The short answer is: preprocessors.  OEA doesn't handle preprocessors, for the most part it pretends they don't exist.  Preprocessors greatly complicate things especially when adding break points.  It isn't possible within OEA to calculate the line number of a .p based on the line number of a particular include. Because the .i is effectively gone after something is compiled you actually need the line number of the .p where the include file is finally compiled.  One particular include file may be included in hundreds (thousands?) of different locations in different source files.  So setting that break point would require that you set a break point in every .p in every location where it is used.

We opted for the simple solution which was to allow you to set a break point within the .p and we would "break" at the first line of the include file.

The debug block contains some offset information for include files in the r-code but this is "one way" -- from a .p to its include files.  Whereas setting a breakpoint in a .i would require that it be mapped in the other direction -- from the .i to everywhere that line from the include file results in executable code with an identifiable line number inside a .p or .cls.

It isn't a bug and it never worked properly in previous versions.  You can certainly log it as a feature enhancement.

Matthew, can you confirm that DEGUGGER:SET-BREAK().  does always work in include files?

Works for me (also in OEA), but maybe there are cases where that also fails.

I can't really comment on the behavior of set-break() as I don't work on the runtime/language.  If it isn't working in some situations you would need to discuss it with tech support since they have the resources to research it and log any issues.

I understand the problem you have with the breakpoints set in the editor when there's no debug-session running.

But let us talk about running instances. The workaround Mike mentioned works fine, but doesn't allow you to toggle the breakpoint while debugging.

Why is it perfectly feasible in the Progress Debugger to put a breakpoint on an include file?

I can imagine that the initial version of OEA didn't come with all the features to support ABL, but include files and preprocessors are essential components.

So, yes, I find it very strange that an OEA plug-in like the debugger isn't more aligned with the functionality already provided in the referenced debugger (i.e. the original Progress Debugger).

I'll log it as feature "enhancement" although I find it a basic capability of the debugger.

The debugger:set-break() is compiled directly into the code.  It is a runtime statement, not a compile time directive.  This means it becomes part of the .r code and is executed just like any other statement whenever it is encountered.  If you put it into an include file and that include file is included in 1000 different places, that single line of code becomes 1000 executable statements after it is compiled.

The current "standalone" debugger works only with preprocessed files.  It doesn't handle raw source code that still contains preprocessors.  While you can set a break point, you are doing so in relation to the the preprocessed code' line numbers, not the original source' line numbers.

In the standalone debugger you only see the preprocessed code, but you can easily set a breakpoint anywhere in that one file since all the line numbers have already been resolved.  This allows you to set the breakpiont even within the statements of the expanded include file.  The downside is you can't see where the original code actually came from without reading through the listing comments, and if you want to set a breakpoint everywhere that include file is used you still have to set it in all of the other places where it gets used.

In the OEA debugger, you get to see the original code and the debugger will follow stepping in and out of the include file and position to the line in either the .p or the .i as appropriate.  You still have the same problem though.  If an include is used in multiple places you have to set individual breakpoints in each of those places it is used.  You can still set breakpoints from the breakpoint view assuming you know the expanded line of code where the include file statement ends up.

Currently, it is a tradeoff between working with breakpoints in include files and seeing your code as it you wrote it.

Definitely log an enhancement request though since it is a desirable feature.

Squeaky wheel...