I've uncovered what I think is either another, or perhaps a root
solution to the PowerBASIC 3.5 IDE debugging line count sync loss
that we face in large projects. I got a chance to see this fix,
for the first time without any of my huge collection of internested
calls and so on. I did need all the huge public variable list and
large arrays for a project, but, in the main, the whole thing was
benign, yet terrible off-line synced for debugging.

I had to either fix it, or give up. There *IS* a fix, at least here!

As part of the now-defined, at least for us, edict that I have to
support all the PB 3.5 stuff for DOS for seven more years, as well
as whatever I move onward to in both WIN, UNIX, and OS/2 plus in
DOS, I simply have to experiment with converting the whole now
800,000 line PB 3.5 suite to C++. At least for test purposes, that
has to be done for some executables .. now .. I can't wait and the
only cross-platform compiler I have that seems to do a nice job of
inter-relating the whole mess is the Watcom C++ V11 (b). Mine's
long since paid for, but Watcom V11 (c) will be Open Source, and
that's important, as far as I can see in the compiler business,
where changes leave investments in the dust like a Texas tornado.

The translator is for what *I* need, not what might be a univeral
product, simply as a test excercise to merge what I've seen in BCX,
CBreeze, OBASIC, and other translator research work. It's strictly
a research effort here at this point.

So .. I've invested a fair number of hours in a cross-translator for
PowerBasic to C++. For my purposes, in that all the code was written
toward this, I use so few unique functions, it really hasn't been
all that bad a job .. so far.. The huge collection of nested do loop
operations with a few file openings and closings tripped this latest
solution to the sync loss in the PB IDE ..

It takes *TWO* specific 'fixes' to cure the IDE sync loss here now:

1.) Without fail, after the original DIM statements
in the top part of the program, I find it necessary
to add a *NUMERIC* line lable after the last DIM

DIM DX$(1000)
DIM DX2$(1000)
1000 GGG% = 1 ' First real code line after above!

This gets rid of the first mis-sync source, so far
for me, every time. There is always one here after
the last DIM statement, unless I do this!

2.) I find that I can't tell WHICH one always produces the
next sync loss, and in what combination of interior
DO - LOOP or whatver. I can tell that if I simply add
a NUMERIC line lable directly after *EACH* CLOSE
statement or group of them in file operations ..

no more IDE sync loss!

1500 GGG% = 1 ' Useless do nothing lable!
PRINT "My dog has fleas!"

Without the NUMERIC line lable, the sync loss
starts just after a CLOSE statement, somewhere.
A non-Numeric lable doesn't do it! It takes a
NUMERIC line lable to do it.

If the file operations are out there in SUB routines, that seems to
be one of the elusive ways that you can produce this thing. Do
not know why, but you can add a simple PRINT statement after a
file CLOSE and see which one does it. It's simpler just to add
the line number after each and forget the mess.

I had stumbled on to this earlier in the collage of 'fixes' that
seemed to cure it, but this is the first time I've ever been able
to reduce it to the simplest form above.

In case you think this is a departure from my liking for PowerBASIC,
it is *NOT*. We really do not dream of how nice we have things in
PowerBASIC until we are forced to go elsewhere to feed.

If I only could get to see the LINUX version and then .. in my
wildest imagination, get someone to pay enough to Bob to release the
work that was started to OS/2 as a finished product, I would be
smiling, smiling, smiling..

I happen to *VERY MUCH LIKE* the PowerBASIC operation and crew. It
is a superb product, one that I know I *CAN* rely on for the seven
year itch I now face...

Maybe this will help us all here solve this thing...

Mike Luther
[email protected]