Author |
Topic: Bug - or unrecognised feature? (Read 232 times) |
|
KenDown
New Member
member is offline
Posts: 49
|
 |
Re: Bug - or unrecognised feature?
« Reply #6 on: Dec 22nd, 2017, 1:16pm » |
|
Hmmmm. I repent in dust and ashes!
However, although on its own @vdu%!220 (with or without the POS) returns the right answer for the height of a font, it must conflict with something else in my program because it mucks up the values returned by WIDTH() (or mucks up how I deal with them, or something). I'll have to look into it more.
VDU23,16,64;0;0;0; causes the behavour I'm looking for (scrolling text starting off the screen to the right and ending off the screen to the left). Thanks for that and apologies for not realising that it was there.
Is VDU23,16,0;0;0;0; the default? ie. If I do that after my scrolling routine has finished, will I be back to square one, so to speak?
|
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: Bug - or unrecognised feature?
« Reply #7 on: Dec 22nd, 2017, 2:02pm » |
|
on Dec 22nd, 2017, 1:16pm, KenDown wrote:| Is VDU23,16,0;0;0;0; the default? |
|
Yes.
Richard.
|
|
Logged
|
|
|
|
KenDown
New Member
member is offline
Posts: 49
|
|
Re: Bug - or unrecognised feature?
« Reply #8 on: Dec 22nd, 2017, 8:42pm » |
|
Thanks. I really appreciate your replies. A very big help.
|
|
Logged
|
|
|
|
KenDown
New Member
member is offline
Posts: 49
|
|
Re: Bug - or unrecognised feature?
« Reply #9 on: Dec 23rd, 2017, 02:21am » |
|
Curioser and curioser. A friend with whom I have been corresponding over this matter sent me the following program.
f$= "FONT Arial,32,B"
a$="Kendall Down"
b$="Kendall "+CHR$18+CHR$0+CHR$9+"Down"
OSCLI(f$)
VDU5
MOVE100,400:PRINTa$, WIDTH(a$)/2, @vdu%!220
MOVE100,300:PRINTb$, WIDTH(b$)/2, @vdu%!220
MOVE100,200:PRINTb$, WIDTH(b$)/2, @vdu%!220
MOVE100,100:PRINTa$, WIDTH(a$)/2, @vdu%!220
VDU4
END
When you run it the numbers in the top and bottom lines are further to the right than the numbers in the middle two lines. Now reverse the order of the lines, so that the two lines with b$ are at top and bottom and the two lines with a$ are in the middle. Run it again and it is *still* the top and bottom lines which have the numbers offset to the right!
I blame the litte green men on Mars, myself.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: Bug - or unrecognised feature?
« Reply #10 on: Dec 23rd, 2017, 10:09am » |
|
on Dec 23rd, 2017, 02:21am, KenDown wrote:| When you run it the numbers in the top and bottom lines are further to the right than the numbers in the middle two lines. |
|
There's nothing strange going on here. What you are forgetting is that there are features of the PRINT statement which work properly only when all the characters output have the same width; specifically they are right-justified printing of numbers (which is the default) and tabulation using the TAB(n) function or the comma delimiter. The program you listed uses both right-justified numbers and the comma delimiter, so it is not surprising that it misbehaves.
PRINT simply counts the characters (bytes) you output - you can get the current value from the COUNT function - and assumes they all occupy the same width on the screen. When it tries to align the text to a specific column it outputs a number of spaces based on the current value of COUNT. If you select a proportional-spaced font, or use UTF-8 encoding, or incorporate 'non-printing' characters in strings, this doesn't work.
In that case you must take responsibility for formatting yourself, so if you want to have numbers printed right-justified, or tabulate output in columns, you cannot rely on the built-in features of the PRINT statement. Instead you will need to convert the numbers to strings (STR$), measure their width (WIDTH) and MOVE the graphics pointer to the appropriate place to achieve the required alignment.
Richard.
|
|
|
|
|
