MV> Hallo Tim Hutzler, hoe is het ermee?
Huh??? 
 
TH> I use Qedit to run PBC, and it works quite nicely. If there are
  > compile errors, my macro pulls up the file and points to it. It's
  > not much good for run time errors, however; so I still need both.
MV> Isn't there a way to find out were the runtime error occured?
I'd sure like to know... 
The answer may be found in the use of PBD, but I am surprized that PBD
is barely mentioned and not documented in wither the user nor
reference manuals. Bummer.
MV> What does the 'pgm-ctr' stand for if you get a runtime error?
I think that is the value of PC (stands for Program Counter, a
register that points the processor to the current instruction/OP-code.
MV> Couldn't it be used to get the line of the error?
PBC takes a command argument "/OM" that generates a .MAP file that has
xfed info, but they don't seem to correctly correspond to the line
actually making the error in the source code. Further, the xref is in
hex and the error is in decimal.
MV> PB itself must have some way to do it, doesn't it just run the
  > EXE itself?
 
Of course, it does. It doesn't use PBD however, but some internal
process that I can not access. The IDE is well done in most aspects,
but the editor is crap, IMHO. They really should have made it more
programmable, like QEdit.
Because of the lack of documentation for PBD, and because it does not
seem to function properly (I got an out of memory error on a rather
small program) I'm inclined to delete it and forget it.
If I create a run time problem, and I can't figure it out, I will go
into PB and let it tell me what the error is. The debugger in there
seems to be okay, though I haven't had to lean on it that much.
Because the IDE is so crummy, I have been developing my own editor. It
isn't that hard to write one, but it is still time consuming.
 
--- Maximus/2 3.01
---------------