Hi Lee, Yes, I am most satisfied, thanks so much, yours is a very nice reply.
I was thinking first off perhaps you was up to doing some SBASIC self-modifying code - I wonder if anyone has ever tried this. There could be some instances where doing this could make the code more efficient - who knows? It turns out though you are using this for REM statements - apparently simple stuff. Nevertheless these ideas that start out being easy in nature can sometimes produce lots of bugs. It can be very nerve-wracking at times. We write code to do something in particular - and it doesn't work, and can take ages to fathom out. Anyway, I hope my attempts at trying to resolve this particular issue turns out to be helpful. All the best, Michael > On Wed, 4 Oct 2017 at 10:49, Lee Privett <lee.priv...@gmail.com> wrote: > Thanks guys and especially to Michael, and to his last few questions. > Firstly I placed the query (cut down) to avoid a lengthy and possibly > boring explanation > I am periodically (while I can) in pre-production of a lengthy project that > I have dabbled in over the last two years and as I think about aspects of > the project, mini projects pop into mind. These result in functions or > procedures that I test out and if useful, I publish in QUANTA. > > One such project is so large that the programming for it has to be fairly > rigorously planned out, which amongst other things includes plenty of REM > statements. > So I am writing a procedure called AutoREM which asks two questions, what > line to start at (An) and what it is all about (Final$), it will then > create REM statements and eventually DEF PROC and END PROC lines > automatically, all within the SMSQ/e environment. Specifically at the > moment QPC2. Although not compiled a version of this will be used in the > "big project" which will be. > > I hope that satisfies your intrigueness (not a real word) Michael. > > Lee > Lee > On Wed, Oct 4, 2017 at 9:42 AM, Michael Bulford via Ql-Users < > firstname.lastname@example.org> wrote: > > > 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 abort. > > > > 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 > > continuing. > > 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 > > "CONTINUE"&CHR$(10):STOP > > 1930 TYPE_IN (An+1)&Top$&CHR$(10) :IF NOT COMPILED:TYPE_IN > > "CONTINUE"&CHR$(10):STOP > > 1932 TYPE_IN (An+2)&Final$&CHR$(10):IF NOT COMPILED:TYPE_IN > > "CONTINUE"&CHR$(10):STOP > > 1940 TYPE_IN (An+3)&Top$&CHR$(10) :IF NOT COMPILED:TYPE_IN > > "CONTINUE"&CHR$(10):STOP > > 1950 TYPE_IN "CLS#2:LIST"&CHR$(10) :IF NOT COMPILED:TYPE_IN > > "CONTINUE"&CHR$(10):STOP > > 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! > > > > Michael > > _______________________________________________ > > QL-Users Mailing List > > End of Ql-Users Digest, Vol 164, Issue 3 **************************************** _______________________________________________ QL-Users Mailing List