Hi,

first, your program stops executing the END statement so it's no question
why it stops but why it does reach this line.Executing an END statement
always closes all open files.

Second, the error might be caused due to some code outtside the loop making your code difficult to check. Using GOTO <linenumber> is possible but you
have to take care that your code will later on jump back into the loop. PDS supports GOSUB with labels, so to get better readable and checkable code you should use GOSUB <label> in conjunction with <label>: and RETURN to get a better readable and checkable code structure. A still better way is to use subroutines with SUB <subname>...RETURN.

Generally, PDS does not need line numbers at all. Forget all line numbers
and use labels, this will make your code significantly clearer and more readable, and insert blank lines for separation to enhance readability. The more readable your code the better checking for errors it is. Empty lines
are ignored by the compiler and therefore do not enlarge file size.

Third, it's not a good practice to add graphical files as attachment. You
can add code simply as plain text into your mail, or if you insist to add a code file use txt format at least, this will enable us to copy out your code for better reading, more tests, and so on, if nescessary. The included GIF
file is of poor quality and therefore harder to read than nescessary.

Your trial to understand code execution by reporting line numbers is not
very effective as you see, because it's hard to maintain variable values to find out which conditions will branche.

For easier debugging use something like this:
MSG$ = "<code location>: <variable name> = <variable's content>
CALL DBGOUTPUT (MSG$)
:::

SUB DBGOUTPUT (M$)
PRINT M$
END SUB

Fourth, never, never change FOR...NEXT loop variables inside or outside the loop as you do here.
If you need to change such a value use a WHILE...WEND construction with a separate loop counter variable which can be incremented as you want and used
to exit loop.

HTH, wuez

BTW: do you still use PDS and MS DOS, or do you PDS run in a command line window (I never tried this but it might work)?



Basic PDS 7.1



"Robert Baer" <robertbaer@localnet.com> schrieb im Newsbeitrag news:FEc1H.81519$lZ.36976@fx12.iad...

I am having a devil of a time tying to figure out why a BASIC program
does not work properly.
Had been using the BASIC Professional Development System Ver 7.1 (equivalent to Quick BASIC from DOS 6.22 daze).

Inserting a bunch of debug print lines did not help much; in a
section of the program, 6 statement lines got executed in 1,3,5,2,4,6
order instead of the expected, listed 1,2,3,4,5,6 order.

I got tired of fighting it so converted the program into a
line-numbered version and made the obvious reference changes for GWBASIC
DOS 3.3).

Attached is a screen shot montage showing one still messy section of
code, along with a TRON.

Notice the program stops at line 530 for no good reason, and all
files are closed.

One would think that a more regimented, line-numbered program would
behave.

Help?

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Robert,

Notice the program stops at line 530 for no good reason,
and all files are closed.

Under QBasic 'end' terminates the program. Are you sure you didn't mean
'end if' there ?

(That all the files are closed could easily be part of PDS'es clean-up activities before actually terminating)

in a section of the program, 6 statement lines got executed
in 1,3,5,2,4,6

As you have not posted the involved code and I (we) do not have any kind of mind-reading capabilities there is nothing I (we) can say about that.

One would think that a more regimented, line-numbered
program would behave.

It certainly enables you to write goto-enabled spagetti code (as in: unreadable/trackable code). Why do you think most languages dropped the 'goto' and/or strongly advice you NOT to use it ? :-)


Basic bug-hunting most often boils down to isolating the problem by removing everything that does /not/ make the problem disappear (and sometimes
replacing variable and/or human input by fixed stuff). If you're lucky
you're left with a single line. :-)

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

R.Wieser wrote:

Robert,

Notice the program stops at line 530 for no good reason,
and all files are closed.

Under QBasic 'end' terminates the program. Are you sure you didn't mean
'end if' there ?

* In one iteration of the program, that is what was intended..

(That all the files are closed could easily be part of PDS'es clean-up activities before actually terminating)

in a section of the program, 6 statement lines got executed
in 1,3,5,2,4,6

As you have not posted the involved code and I (we) do not have any kind of mind-reading capabilities there is nothing I (we) can say about that.

One would think that a more regimented, line-numbered
program would behave.

It certainly enables you to write goto-enabled spagetti code (as in: unreadable/trackable code). Why do you think most languages dropped the 'goto' and/or strongly advice you NOT to use it ? :-)

Basic bug-hunting most often boils down to isolating the problem by removing everything that does /not/ make the problem disappear (and sometimes replacing variable and/or human input by fixed stuff). If you're lucky you're left with a single line. :-)

* Now THAT would be rather nice..do my taxes in one line...

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Wendelin Uez wrote:

Hi,

first, your program stops executing the END statement so it's no
question why it stops but why it does reach this line.Executing an END statement always closes all open files.

* Thanks; it as been over 40 years since i have used GWBASIC and 15
years since using PDS Basic.
I finally figured out that "END" meant end-of-program.
It got into the program from previous ierations,one having an IF..ENDIF.

Second, the error might be caused due to some code outtside the loop
making your code difficult to check. Using GOTO <linenumber>  is
possible but you have to take care that your code will later on jump
back into the loop. PDS supports GOSUB with labels, so to get better
readable and checkable code you should use GOSUB <label> in conjunction
with <label>: and RETURN to get a better readable and checkable code structure. A still better way is to use subroutines with SUB <subname>...RETURN.

* finally switched back to PDS, as no manuals for GWBAIC or equivalent;
numbers gone (see below).

Generally, PDS does not need line numbers at all.  Forget all line
numbers and use labels, this will make your code significantly clearer
and more readable, and insert blank lines for separation to enhance readability. The more readable your code the better checking for errors
it is. Empty lines are ignored by the compiler and therefore do not
enlarge file size.

* atarted no line numbers and blank lines blank lines became
number..comment (120 ').

Third, it's not a good practice to add graphical files as attachment.
You can add code simply as plain text into your mail, or if you insist
to add a code file use txt format at least, this will enable us to copy
out your code for better reading, more tests, and so on, if nescessary.
The included GIF file is of poor quality and therefore harder to read
than nescessary.

* I see no quality problem in the posted GIF file, it is as good as the original visual, in fact the TRON is more readable because i inverted
black and white.

Your trial to understand code execution by reporting line numbers is not
very effective as you see, because it's hard to maintain variable values
to find out which conditions will branche.

For easier debugging use something like this:
MSG$ = "<code location>: <variable name> = <variable's content>
CALL DBGOUTPUT (MSG$)
:::

SUB DBGOUTPUT (M$)
PRINT M$
END SUB

Fourth, never, never change FOR...NEXT loop variables inside or outside
the loop as you do here.
If you need to change such a value use a WHILE...WEND construction with
a separate loop counter variable which can be incremented as you want
and used to exit loop.

HTH, wuez

BTW: do you still use PDS and MS DOS, or do you PDS run in a command
line window (I never tried this but it might work)?

* find that PDS works with full visual screen as if ADM-3 in Win XP very nicely.
House-some ever, in Win7.1, even tho you can have visual screen full
in CMD prompt, it is impossible to get those larger characters for same
ADM-3 effect.
An 1024x768 screen or 1152x864 screen becomes max of 144w x 66h, 8x12 (raster font) fills monitor nicely with small but readable text.
However, QBX only fills about 2/3 of it with "large" font 80 wide.
GWBASIC does the same. No nice "fill it up" like in XP.

Thanks.

Basic PDS 7.1

"Robert Baer" <robertbaer@localnet.com> schrieb im Newsbeitrag news:FEc1H.81519$lZ.36976@fx12.iad...

  I am having a devil of a time tying to figure out why a BASIC program
does not work properly.
  Had been using the BASIC Professional Development System Ver 7.1
(equivalent to Quick BASIC from DOS 6.22 daze).

  Inserting a bunch of debug print lines did not help much; in a
section of the program, 6 statement lines got executed in 1,3,5,2,4,6
order instead of the expected, listed 1,2,3,4,5,6 order.

  I got tired of fighting it so converted the program into a
line-numbered version and made the obvious reference changes for GWBASIC
DOS 3.3).

  Attached is a screen shot montage showing one still messy section of
code, along with a TRON.

  Notice the program stops at line 530 for no good reason, and all
files are closed.

  One would think that a more regimented, line-numbered program would
behave.

   Help?

   Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Robert,

Under QBasic 'end' terminates the program. Are you sure you didn't mean
'end if' there ?

* In one iteration of the program, that is what was intended..

You do not make much sense there. You complain that it stops there, and now you're telling me that was intended ? <huh?>

Besides, the indentation tells me that that 'end' was /ment/ as the
terminator of the 'if' above it ...

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

R.Wieser wrote:

Robert,

Under QBasic 'end' terminates the program. Are you sure you didn't mean >>> 'end if' there ?

* In one iteration of the program, that is what was intended..

You do not make much sense there. You complain that it stops there, and now you're telling me that was intended ? <huh?>

* The "END" stop was not intended, it was the left-over from an intended IF..ENDIF.

Besides, the indentation tells me that that 'end' was /ment/ as the terminator of the 'if' above it ...

* Ain't that what i sed?

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Robert,

You do not make much sense there. You complain that it stops there, and
now you're telling me that was intended ? <huh?>

* The "END" stop was not intended, it was the left-over from an intended IF..ENDIF.

Thats what I said the in my initial response to you/it, which you only /now/ acknowledge.

Odd though, I would have expected that code (the unterminated "if") to have thrown an error (QBasic certainly does), but I have not seen you mention anything like it....

Besides, the indentation tells me that that 'end' was /ment/ as the
terminator of the 'if' above it ...

* Ain't that what i sed?

You did ? You mean when you said "In one iteration of the program, that
is what was intended" ? I can read that in at at least four different ways (two possibilities left of the comma, two right of it), so I pretty-much ignored it.

Kiddo, as I have zero wish to second-guess what you might have ment when you say or write something I can only wish you good luck with your further bug-hunting.

Regards,
Rudy Wieser

P.s.
As you mentioned that you do not see all posts : I also wrote a reply to
your "Rev1" message. It might be usefull to you.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)