Dear Concern,

At the time of compiling report in debugger mode it is showing, system generated code also but we want to go to the particular progamming code. To check the report output.Please suggest the command for this.

Regards,
Arya

You can search for your code by typing the search string preceded by a /.

Hi,

As Jaap rightly said, you can find the patters in the code by using a "/", but I guess you won't be able to set breakpoints in some cases.

So, to set the breakpoints you can use a temporary variable and assign it some value in your report script at the part of code which you want to debug. Now, when you go into the debugger do a

t variable_name and hit enter and continue. Now, you can debug the rest of the code following the variable line by line.

And the way I do it is I search for my code as both Bhushan and JaapJD mention. I found my code and see what function it is in. Then I search for that function and put my break point on that function. Then after the report gets running once you hit that function you can put additional break points inside the function. Just another way to accomplish the same thing.

I think the start of this post meant getting into the report script, not the system-generated report code. You would have to set a breakpoint on one of the layouts and then step into it.

You can also use the "stop in" command in debug. say, for instance, you have a function called get.customer(), when debugger starts, you can type "stop in get.customer" and you will stop each time that function is called.

Hi,

But what if there are no functions written but only a few lines of code in every section. In that case, you have to set the breakpoints in other way after following the patterns.

Here's what I do, when I need to debug a reportscript:

Sadly there no single command to get into the report script to perform debugging. If the report is compiled in debug mode it will always start with the system generated code in the debug window.

You need to know that every before- or after-layout section in the report script is called by a specific function in this generated code. You need to identify a section that will be executed when printing the report, find this connected function and set a breakpoint on that function call.

Let's assume you do know that before.detail.1 is executed in the report. The connected function will be named r.s.detail.1.bef.lay() in the generated code and it's embedded in an if-then statement:

if ( lattr.print ) then
r.s.detail.1.bef.lay()
endif

Usually I just search the script for the section.name, i.e. "detail.1":
/detail.1

Now you just set a breakpoint on the r.s.detail.1.bef.lay()-line and continue the report. The debugging will stop at the breakpoint and you just step into the function. The debug window will now reload and show the report script you edited. There you can scroll and set breakpoints in every sections you want to debug. Now continue the report. The report will stop at the selected breakpoints, when they are hit.

If your report has a before.program section in its script, you can use the r.s.before.program() call to step into the report script. You'll find this function right below the entry point of the generated script, when the debug-windows opens. It's called in the main()-function.

This may not be the perfect way to debug a report script, but it still works for me. :)

Regards,
Andreas

I'm using the following code to find my code in a comfortable way:

before.program:
e = 1


So, when the report start, I do a 't e' (stop when e changes) to switch to my code.

Regards, Günther

I'm using the following code to find my code in a comfortable way:

before.program:
e = 1


So, when the report start, I do a 't e' (stop when e changes) to switch to my code.

Regards, Günther


Ditto :) A variable doesn't cost you much ;)

Becareful - I believe e is a predefined variable. :)

Becareful - I believe e is a predefined variable. :)

Good catch Mark. A variable can be dangerous at times if you add a "pre-defined" ;)