Revelation,

Is it possible for you to modify the debugger so that it shows more columns. Its pretty painful when you're debugging a program that has a lot of arguments passed to it and you can't scroll across to the right far enough to see what they are.

Yes, I know its bad programming practice to pass heaps of arguments rather than an array, but these are usually other peoples programs.

Paul,

Yes, I know its bad programming practice to pass heaps of arguments rather than an array, but these are usually other peoples programs

From that description they could be some of my programs.

But seriously - I totally agree with you. The horizontal scrolling capability of the Debugger is puny indeed. And the problem isn't just with stored procedure calls. Other program lines can get long too. And for very valid reasons, like having descriptive, and therefore long, variable names; like using lots of horizontal spacing to make the program more readable; etc.

If only instructions could be broken into several lines. Then we could keep the line length down. I really can't think of other programming languages that don't allow continuation lines.

- Oystein -

Oystein,

Basic+ does support multiple line statements, but currently only across two lines (I suspect this to be a bug rather than by design).

To do it just use a "|" character at the end of the line…

eg…

retVal=someLongFunction( arg1, arg2 arg3, |
                           arg4, arg5 )

The Sprezzatura Group

World leaders in all things RevSoft

Sprezzatura,

Got a deja vu-oid feeling when I wrote multiple line statements were impossible. Couldn't decide if that was because I've claimed the same before, or because I've been corrected before. I don't think it's docced, though. I checked that.

You say "currently only … two lines". It going to change?

- Oystein -

Sprezzatura,

Each multiple line statement (i.e, two line statement) causes the Debugger's linecount to be off by one line.

- Oystein -

Oystein,

I don't think it's docced, though. I checked that.

Look in the Basic+ Help for the section headed "BASIC+ Syntax Rules". Theres a bullet point that says:

"The | character tells the compiler that the following line is an extension of the current line."

You say "currently only … two lines". It going to change?

I dunno … Mike?

The Sprezzatura Group

World leaders in all things RevSoft

Interesting..

Quick testing here shows that a VNAV on the second line reports as an error on the first line? Is this what you are referring to, or something more serious?

(This is not wholly unexpected as I believe a precompiler concatenates the second line to the first before true compilation…)

As for multiline support in other languages… most handle it by an end of line symbol ( typically a ';' ) which I for one am grateful I don't have to bother with in Basic+ ! :)

Still if you're really keen you could write something like a Javascript to Basic+ cross compiler - that would be really fun ;)

The Sprezzatura Group

World leaders in all things RevSoft

Sprezzatura,

Let's say I have a stored procedure with two two-line statements and a debug statement:

function Test( Dummy )

debug

A=1

B=2 + |

2

C=3 + |

3

D=4

return 0

When I step through the code with the Debugger the highlighting is consistently two lines below where it should be.

You're correct that multiple line statements is docced. But it couldn't hurt with some keywords, e.g:

- "Multiple line statements"

- "Continuation lines" (or something similar)

- "|"

- Oystein -

Oystein,

When I step through the code with the Debugger the highlighting is consistently two lines below where it should be.

Hmm… seems fine here .. debugger is right on target.

The Sprezzatura Group

World leaders in all things RevSoft

Sprezzatura,

You're probably right. Something else must have thrown my Debugger off target.

- Oystein -

You're probably right. Something else must have thrown my Debugger off target.

Inserts within inserts can cause this to happen.

[email protected]

SRP Computer Solutions, Inc.

Sometimes the Debugger comes up when not called for by errors or debug statements. Here's an example:

I have a function with a few simple statements, ending with a return statement. I put a debug statement somewhere near the beginning (see below). I run the function from the System Editor Exec Line. I use F10 and/or F5 to step/go through the whole function. Afterwards I recompile the function.

Scenario 1:

I use F5 to get to the end of the function. I might do a few F10 before the F5, but I do F5 before I reach the very end. This causes the Debugger to close. Back in the System Editor when I recompile the function there is no problem.

Scenario 2:

I step with F10 to the very end of the function. This causes the Debugger's menus to change to the simple form with just a File and a Help menu. I close the Debugger (with Alt+F4 or File | Exit). Back in the System Editor when I recompile the function the Debugger comes up again with no source code and the following stack:

REV_LINE_LOC

REV_COMPILER

REPOS.STPROC..COMPILE

REPOSITORY

Why?

- Oystein -

---

function Test_D( Dummy )

A=1

debug

B=2

C=3

D=4

return 0

Guess the correct procedure in scenario 2 is to do File | Break first, and then F5. So my question might be why a the effect of a large number of F10s don't equal a F5? And why killing the Debugger causes it to rise from the dead at next opportunity, like the recompilation I do immediately afterwards.

On second thought - don't bother…

- Oystein -

Don,

Must have been something simpler this time. A blank line, a comment line, or something. That's all I had beside simple assignment statements, two-line assignment statements, and the return statement.

- Oystein -

Oystein,

I've seen that before as well. I've always understood that stepping through the debugger (F8 or F10) does not turn SPY off whereas F5 will turn it off when the code is complete. Therefore the next time code is executed the debugger kicks back in, even if it is system code.

[email protected]

SRP Computer Solutions, Inc.

Don,

Thanks for the explanation. I don't understand this SPY thing, though.

- Oystein -

View this thread on the Works forum...