The fact that this code

0001 * test
0002 call sub(a,b,c
0003 ,d,e,f)


will not compile with the flash option is not a bug, imo. The fact
that it does compile in regular, non-flash mode is the bug. I don't
know of any other basic funtions or commands that will compile when
spread over multiple lines.

How about:

open "file"
to fv else stop 201

or

x = oconv(
date(),"d2-")

BTW, here is what happens when I try to flash-compile the call sub
example:
(d3/linux 7.4.2.A202)

:compile bp sb (o
sb
0002 call sub(a,b,c
[B102] Line 2: Bad statement.
0003 ,d,e,f)
[B102] Line 3: Bad statement.
B102
3
[B100]*Line 0: Compilation aborted; no object code produced.

So on this system, at least, the compile seems to give a pretty clear
indication of where the problems are.

As mentioned previously, there are some variants of this that will
(unfortunately) flash-compile:

0001 * test
0002 call sub(a,b,c,
0003 d,e,f)

however, just because it compiles does not mean it will run:

:run bp sb
[876] FlashBASIC object of program 'sb' was created on
a different machine - please recompile.

This, I think, is a legitimate bug.

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

Ultimate, Sequioa, UV and Unidata solved this problem long time ago.

Trivial to determine if the var is in common and not release, and to prevent
double restore, etc (CALL X(A,A,A). If RD has not done it, just shows how
utterly incompetent they are (or uncaring)

Chandru

"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote

Not on D3 it doesn't.

mbp 'testx' size = 65 filed
Flash (Y/N/X/C/O/Z): ?c
testx
0001 subroutine abc(a,b,c
[B102] Line 1: Bad statement.
..
0002 d,e)
[B102] Line 2: Bad statement.

[B100]*Line 7: Compilation aborted; no object code produced.


Mark

"Dale" <dale_benedict (AT) flightcraft (DOT) ca> wrote

You need a comma at the end of the line:
0001 subroutine abc(a,b,c,
0002 d,e,f)

Chandru
"Mark Brown" <mbrown (AT) drexelmgt (DOT) com> wrote

As usual, I agree with Scott's evaluation that this is a bug. But
this is one of those areas where the bug may be able to invoke a
grandfather clause such that it should not be fixed. It depends on
when the "feature" crept in that allows a CALL to break across lines.

I think the real solution to this and many similar issues is a series
of OPTION flags like we see in other platforms, where if you want or
don't want a certain behaviour that was valid in some prior release,
you need to set or unset a flag for it. This can be set in a logon
macro, individual code, or maybe in an item in the program file.

Regarding which statements do or do not break across lines, I could
have sworn I read somewhere a couple years ago that line breaks are
allowed for COMMON, and possibly for CRT/PRINT (certainly not CALL).
That could be platform specific and not even apply to D3, dunno.

T

"Scott Ballinger" wrote:

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

A "feature" as allowing line breaks at commas could not possibly break
anything. Practically all Pick compilers allow breaks at commas on many
statements (uv on all) , it's not something that "crept" in, it's a
conscious change to the compiler.

Chandru