Hi all, 

I am hoping now to explain what is going on.  First, here is some code that 
does work .. 

100 DIM Top$  (100) : Top$   = "REMark " & FILL$( "*"  ,20) 
110 DIM Final$(100) : Final$ = "REMark " & FILL$("text",20) 
120 An = 20000 
1920 TYPE_IN An&":"&CHR$(10) 
1930 TYPE_IN (An+1)&Top$&CHR$(10) 
1932 TYPE_IN (An+2)&Final$&CHR$(10) 
1940 TYPE_IN (An+3)&Top$&CHR$(10) 
1950 TYPE_IN "CLS#2:LIST"&CHR$(10) 
1960 PRINT #0,"Program completed successfully" 

After running the above code, you may notice that the “completed” message does 
not appear. 
To explain why, we have to consider how this code works.  If this code is 
compiled, then SuperBASIC will act immediately upon each of the TYPED_IN 
commands.  Under the Interpreter, they will not be acted upon, but will get to 
be stored in #0’s buffer.  After the “completed” message gets printed to #0, 
the code comes to an end, and the SuperBASIC cursor comes back to life.  The 
contents of the #0 buffer then gets entered into the command line, and will be 
acted upon, scrolling the “completed” message out of the way. 

Now consider what can happen if we change the first line to read FILL$(“*”,60). 
 Running the code again with this larger figure will lead to it “locking up”, 
with nothing apparently happening.  What has happened is that #0’s buffer has 
become full, and it is waiting there for some characters to be removed, which 
never happens.  The only thing to do is to press Ctrl-SPACE and Ctrl-c to 

As long as the buffer length of 128 bytes is not exceeded during a TYPE_IN, all 
should be well. 
Each TYPE_IN will need to be made separately, with the QL stopping, then 
The need to STOP is necessary to force the #0 buffer to empty its contents. 
Notice that we do not STOP if COMPILED, as doing that would remove the task. 
Here is the same code as above with these amendments … 

100 DIM Top$  (100) : Top$   = "REMark " & FILL$( "*"  ,60) 
110 DIM Final$(100) : Final$ = "REMark " & FILL$("text",60) 
120 An = 20000 
1920 TYPE_IN An&":"&CHR$(10)       :IF NOT COMPILED:TYPE_IN 
1930 TYPE_IN (An+1)&Top$&CHR$(10)  :IF NOT COMPILED:TYPE_IN 
1932 TYPE_IN (An+2)&Final$&CHR$(10):IF NOT COMPILED:TYPE_IN 
1940 TYPE_IN (An+3)&Top$&CHR$(10)  :IF NOT COMPILED:TYPE_IN 
1960 PRINT #0,"Program completed successfully" 

The above code works as expected in SMSQ/E.  It should not work under QDOS as 
after entering any new line in the code, QDOS will lose its place and would not 
be able to continue.  For QDOS it is best to compile the code.  Another point 
to bear in mind is that any line TYPED_IN with invalid syntax will lead to the 
SuperBASIC cursor being re-entered to enable the faulty line to be edited.  
There is a simple way to cope with this condition, by starting each TYPE_IN 
with a CHR$(27) - the Escape key. 
This kind of code can be far easier to write and get working if it is compiled 
with Turbo.  After any TYPE_IN to SuperBASIC, Turbo could wait in the 
background, in a loop, monitoring the SuperBASIC cursor position, and 
determining whether the typed-in line was successful or not.  This arrangement 
would allow the user to correct the command line and press ENTER.  Only when 
everything is okay could Turbo decide to exit the loop and continue.  If the 
128-character limit is too restrictive, one could use a temporary MERGE file 
instead of using TYPE_IN. 

This discussion would be more entertaining if we had more details of what is 
trying to be achieved. 
What is being used? - The QL, Q-emuLator or QPC2? - also is this compiled?  I 
notice that each TYPE_IN starts with an integer, which would mean that lines 
are being added to SuperBASIC. 
This is indeed intriguing! 

QL-Users Mailing List

Reply via email to