BBC BASIC
« Bug - or unrecognised feature? »

Welcome Guest. Please Login or Register.
Jan 20th, 2018, 4:19pm


Cross-platform BBC BASIC (Win32, Linux x86, Android, Mac OS-X, Raspberry Pi)

« Previous Topic | Next Topic »
Pages: 1  Notify Send Topic Print
 thread  Author  Topic: Bug - or unrecognised feature?  (Read 109 times)
KenDown
New Member
Image


member is offline

Avatar




PM


Posts: 17
xx Bug - or unrecognised feature?
« Thread started on: Dec 21st, 2017, 08:03am »

I want to find the length of a string which contains colour codes and, as the string will be printed under VDU5, that means adding the string equivalent of VDU18,0,colour

I would have thought that those three characters should *not* be included in the string length, but to my annoyance they are. Am I missing something? The following short program illustrates the problem.


DIMU%300:U%=(U%+1)AND-2
DIMfsize{fontx%,fonty%}
OSCLI("FONT Arial,32,B")
a$="Kendall Down"
b$="Kendall "+CHR$18+CHR$0+CHR$9+"Down"
PROClen(a$)
PROClen(b$)
END
:
DEFPROClen(t$):LOCALL%
OSCLI("FONT Arial,32,B")
SYS"MultiByteToWideChar",&FDE9,0,t$,LENt$,0,0TOL%
SYS"MultiByteToWideChar",&FDE9,0,t$,LENt$,U%,L%
SYS"GetTextExtentPoint32W",@memhdc%,U%,L%,fsize{}
PRINTfsize.fontx%
ENDPROC
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 689
xx Re: Bug - or unrecognised feature?
« Reply #1 on: Dec 21st, 2017, 2:00pm »

on Dec 21st, 2017, 08:03am, KenDown wrote:
I would have thought that those three characters should *not* be included in the string length, but to my annoyance they are. Am I missing something?

Using the more straightforward WIDTH() function - which returns the width in graphics units - I don't see any problem:

Code:
      OSCLI "FONT Arial,32,B"
      a$ = "Kendall Down"
      b$ = "Kendall "+CHR$18+CHR$0+CHR$9+"Down"
      PRINT WIDTH(a$)
      PRINT WIDTH(b$)
      END 

Richard.
User IP Logged

KenDown
New Member
Image


member is offline

Avatar




PM


Posts: 17
xx Re: Bug - or unrecognised feature?
« Reply #2 on: Dec 21st, 2017, 3:42pm »

Thanks, but will WIDTH() deal with UTF-8 characters, such as Bulgarian or even Welsh? That, I am pretty sure, is why the slightly long-winded MultiBytetpWide method was adopted.
User IP Logged

KenDown
New Member
Image


member is offline

Avatar




PM


Posts: 17
xx Re: Bug - or unrecognised feature?
« Reply #3 on: Dec 21st, 2017, 3:44pm »

Ah, I've just looked up the WIDTH command and see that since 6.10a it *will* handle UTF-8. I can sense a major rewrite coming up!
User IP Logged

KenDown
New Member
Image


member is offline

Avatar




PM


Posts: 17
xx Re: Bug - or unrecognised feature?
« Reply #4 on: Dec 22nd, 2017, 05:47am »

Thanks. I've incorportated the WIDTH command and the program runs noticeably faster in consequence. However I still have to use the MultiBytetoWide method every time I change font to find out the height of the font. We need a HEIGHT() command as well!

While I'm at it, there is a major annoyance for me in that under VDU5 text is wrapped - I'm sure that in the BBC Micro VDU5 was not wrapped and simply vanished off the right-hand edge of the screen. It would be good if there could be a flag to set so that either behaviour could be selected.
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 689
xx Re: Bug - or unrecognised feature?
« Reply #5 on: Dec 22nd, 2017, 09:18am »

on Dec 22nd, 2017, 05:47am, KenDown wrote:
We need a HEIGHT() command as well!

I disagree. There's no such thing as 'proportional height' text (!) so the complication that different characters have different widths has no equivalent. Whether it's a monospaced font or a proportional font, the value at @vdu%!220 is an accurate measure of the character (row) height in pixels. This is a documented system variable, and has been for a very long time.

Note that, as with most system variables, in BBCSDL you must perform a 'thread synchronisation' before you can read the value reliably. It's harmless to do the same thing in BB4W so it's as well to get into the habit, for example:

Code:
      sync% = POS
      height% = @vdu%!220 

Quote:
While I'm at it, there is a major annoyance for me in that under VDU5 text is wrapped - I'm sure that in the BBC Micro VDU5 was not wrapped and simply vanished off the right-hand edge of the screen.

You say that you are "sure that in the BBC Micro VDU5 was not wrapped" so how come that when I turn on my BBC Master, enter MODE 1 and then VDU 5,30, text that I type wraps from one line to the next?

Your recollection is faulty, and I would have hoped that you would expect BB4W and BBCSDL to emulate the BBC Micro accurately in this respect, as they do in most others.

Quote:
It would be good if there could be a flag to set so that either behaviour could be selected.

Er, so that would be VDU 23,16... then, which has been implemented (and documented) since the Acorn Archimedes, that's at least thirty years!!

Richard.
« Last Edit: Dec 22nd, 2017, 11:00am by Richard Russell » User IP Logged

KenDown
New Member
Image


member is offline

Avatar




PM


Posts: 17
xx 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?
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 689
xx 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.
User IP Logged

KenDown
New Member
Image


member is offline

Avatar




PM


Posts: 17
xx Re: Bug - or unrecognised feature?
« Reply #8 on: Dec 22nd, 2017, 8:42pm »

Thanks. I really appreciate your replies. A very big help.
User IP Logged

KenDown
New Member
Image


member is offline

Avatar




PM


Posts: 17
xx 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.
User IP Logged

Richard Russell
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 689
xx 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.
« Last Edit: Dec 23rd, 2017, 12:51pm by Richard Russell » User IP Logged

Pages: 1  Notify Send Topic Print
« Previous Topic | Next Topic »

Donate $6.99 for 50,000 Ad-Free Pageviews!


This forum powered for FREE by Conforums ©
Sign up for your own Free Message Board today!
Terms of Service | Privacy Policy | Conforums Support | Parental Controls