Author |
Topic: Text viewport (Read 1065 times) |
|
Edja
Developer
member is offline
Posts: 60
|
 |
Text viewport
« Thread started on: Mar 27th, 2014, 2:48pm » |
|
It seems this time it's my turn to ask for some clarification on text viewports and PRINTTAB.
I did consult the manual's sections on text viewports and the use of PRINT TAB(x,y). And still ...
Code: MODE 30
VDU 28,10,30,50,10:COLOUR 136:CLS:COLOUR 3
PRINT "Tennis 1"
PRINTTAB(12,15) "This is 12,15"
VDU 28,25,10,65,1:COLOUR 140:CLS
PRINT "Tennis 2"
PRINTTAB(41,6) "This is 21,5"
END
When I was typing the code I accidentally mistyped 41 (instead of 21) as the x-coordinate. Now I am surprised to see the "T" outside the text viewport.
There must be a simple explanation but I don't see it.
Eddy
|
|
 Logged
|
|
|
|
rtr
Guest
|
|
Re: Text viewport
« Reply #1 on: Mar 27th, 2014, 3:15pm » |
|
on Mar 27th, 2014, 2:48pm, Edja wrote:| There must be a simple explanation but I don't see it. |
|
The 'explanation' is that if you specify coordinates outside the bounds of the text viewport the behaviour isn't specified; BBC BASIC can do anything it likes in that case. It's a case of garbage-in, garbage-out!
Richard.
|
| « Last Edit: Mar 27th, 2014, 3:34pm by rtr » |
Logged
|
|
|
|
rtr
Guest
|
|
Re: Text viewport
« Reply #2 on: Mar 28th, 2014, 10:38am » |
|
on Mar 27th, 2014, 3:15pm, Richard Russell wrote:| It's a case of garbage-in, garbage-out! |
|
I have added the following note to the documentation of TAB(X,Y): "If the specified coordinates correspond to a location outside the current text viewport the behaviour is undefined":
http://www.bbcbasic.co.uk/bbcwin/manual/bbcwin7.html#tab
Incidentally switching to 'pending CRLF' mode changes what happens:
Code: MODE 30
VDU 23,16,1;0;0;0;
VDU 28,10,30,50,10:COLOUR 136:CLS:COLOUR 3
PRINT "Tennis 1"
PRINTTAB(12,15) "This is 12,15"
VDU 28,25,10,65,1:COLOUR 140:CLS
PRINT "Tennis 2"
PRINTTAB(41,6) "This is 21,5"
END
Richard.
|
|
Logged
|
|
|
|
Edja
Developer
member is offline
Posts: 60
|
|
Re: Text viewport
« Reply #3 on: Mar 28th, 2014, 12:06pm » |
|
Quote:| I have added the following note to the documentation of TAB(X,Y): "If the specified coordinates correspond to a location outside the current text viewport the behaviour is undefined" |
|
Thank you Richard for clarifying this and for adding a note to the documentation. This has become a real solid reference document over the years.
Eddy
|
|
Logged
|
|
|
|
rtr
Guest
|
|
Re: Text viewport
« Reply #4 on: Mar 28th, 2014, 12:36pm » |
|
on Mar 28th, 2014, 12:06pm, Edja wrote:| Thank you Richard for clarifying this and for adding a note to the documentation. This has become a real solid reference document over the years. |
|
In case you're wondering why BB4W allows TAB(X,Y) to move the text cursor (caret) outside the text viewport, here is the gory explanation. It's not uncommon to use POS and VPOS in conjunction with TAB(X,Y) to save, and then later restore, the cursor position. For example consider this routine which can be found in the BB4W documentation under notes on the use of interrupts:
Code: DEF PROCinterrupt
LOCAL X%,Y%
X%=POS : Y%=VPOS
REM. Output some text here
PRINT TAB(X%,Y%);
ENDPROC
For this to work reliably it's obviously important that the cursor can be restored to any position in which it might legitimately be found.
You may think that the only valid cursor positions are within the bounds of the text viewport, but that's not correct because of the way the pending scroll and pending CRLF options behave. For example in 'pending CRLF' mode it's perfectly valid for the cursor to be positioned just to the right of the text viewport at the end of a line. Similarly in 'pending scroll' mode it's valid for the cursor to be positioned just below the text viewport at the beginning of a line.
So TAB(X,Y) has to be able to restore the cursor to those locations, and unfortunately it was to just one such location that your program moved it! I believe Acorn implementations flag the 'pending' status differently, and don't position the cursor outside the viewport, thus avoiding this particular issue.
Richard.
|
|
Logged
|
|
|
|
JGHarston
Junior Member
member is offline
Gender: 
Posts: 52
|
|
Re: Text viewport
« Reply #5 on: Apr 2nd, 2014, 02:05am » |
|
on Mar 28th, 2014, 12:36pm, Richard Russell wrote:| I believe Acorn implementations flag the 'pending' status differently, and don't position the cursor outside the viewport, thus avoiding this particular issue. |
|
The Acorn implementation is substantially the same. In "NoScroll" mode (introduced in Master MOS 3) when the cursor advances off the positive side of the screen POS becomes equal to the screen width, eg in MODE 7 advancing from (39,2) goes to (40,2) until another character is output and the position becomes the "true" state of (0,3) unless a control code sequence is output. Visually, the cursor is displayed in the final column. That lets you print a character in the bottom right hand corner without scrolling the screen, then TAB(x,y) to somewhere else.
|
|
Logged
|
|
|
|
rtr
Guest
|
|
Re: Text viewport
« Reply #6 on: Apr 6th, 2014, 9:11pm » |
|
on Apr 2nd, 2014, 02:05am, JGHarston wrote:| The Acorn implementation is substantially the same.... when the cursor advances off the positive side of the screen POS becomes equal to the screen width, eg in MODE 7 advancing from (39,2) goes to (40,2) |
|
That's interesting - I had naively assumed that POS and VPOS always reflect the visible position of the cursor (they do in BB4W). The behaviour you describe would imply that in Acorn versions you can't (necessarily) save the current cursor position, temporarily move it elsewhere, and then return it to where it was. In the example you gave, TAB(X,Y) cannot move the cursor back to 40,2 in MODE 7.
Of course Acorn versions of BBC BASIC don't support asynchronous interrupts (such as BB4W's ON TIME) but nevertheless I can imagine a situation in which a text-editing application might want to update the contents of a status bar, which could involve temporarily moving the cursor there and then restoring it to its original coordinates. It's rather unfortunate if the obvious approach won't work.
Richard.
|
|
Logged
|
|
|
|
|
