Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.basic.misc > #489

Re: Program execution problem

Subject Re: Program execution problem
Newsgroups comp.lang.basic.misc
References <FEc1H.81519$lZ.36976@fx12.iad> <rida6u$o2e$1@news2.open-news-network.org>
From Robert Baer <robertbaer@localnet.com>
Message-ID <v%e3H.248753$CM.88191@fx01.iad> (permalink)
Date 2020-08-31 15:40 -0700

Show all headers | View raw


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.
>>
> 

Back to comp.lang.basic.misc | Previous | NextPrevious in thread | Find similar


Thread

Re: Program execution problem "Wendelin Uez" <wuez@online.de> - 2020-08-29 12:21 +0200
  Re: Program execution problem Robert Baer <robertbaer@localnet.com> - 2020-08-31 15:40 -0700

csiph-web