Author |
Topic: Bug - or undocumented feature? (Read 139 times) |
|
KenDown
Full Member
member is offline
Posts: 181
|
 |
Bug - or undocumented feature?
« Thread started on: Dec 21st, 2017, 12:31pm » |
|
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. The two strings print the same length, so you would expect them to measure the same length! 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"
VDU5
MOVE100,400:PRINTa$
MOVE100,300:PRINTb$
VDU4
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
|
|
 Logged
|
|
|
|
DDRM
Administrator
member is offline
Gender: 
Posts: 321
|
|
Re: Bug - or undocumented feature?
« Reply #1 on: Dec 21st, 2017, 4:37pm » |
|
Hi Kendall,
This might be a good one to pass by Richard, but my perception would be:
LEN(a$) is a function to return the number of characters in the string, so I'd expect that to include ALL of them, even if some of them represent a VDU sequence. I guess it would be easy enough to write a small function to return the number of printable characters.
It's perhaps reasonable to expect GetTextExtentPoint32W to work out a correct printable length, but in this case the non-printing characters are non-printing because *BB4W* chooses to handle them that way - there's no way I can think of that Windows would know that! Indeed, it might be tempted to consider the ASCII 9 as a tab... Presumably it just assumes any characters you send it are printable.
As part of the work for the SDL IDE Richard put together a short routine to work out how long a printed string would be - I can dig it out if it would be useful, but it might take me a little while...
Edit: I see you did post to the other forum, and got a good answer! It was a learning point for me, and caused me to upgrade the version of BB4W on this computer.
As a note for others, from version 6.10a, Width(a$) returns the printable width of a string, even if it includes UTF8 characters.
best wishes,
D
|
| « Last Edit: Dec 21st, 2017, 4:49pm by DDRM » |
Logged
|
|
|
|
KenDown
Full Member
member is offline
Posts: 181
|
|
Re: Bug - or undocumented feature?
« Reply #2 on: Dec 22nd, 2017, 06:12am » |
|
Thanks for taking the trouble to reply. WIDTH() is considerably faster than the MultiBytetoWide method - for 1,000 iterations MultiByte took something like 23 centiseconds while WIDTH took 1!
The only drawback is that the MultiByte method returns the height of the font in graphics units and there is no corresponding HEIGHT() command, so I have needed to retain the MultiByte routine in the program and call it every time I change font.
|
|
Logged
|
|
|
|
|
