As before, let me ask folks reading this to do a few things first:
1) Grab the following font for use with examples/discussion:
DejaVuSansMono.7z (Size: 159.23 KB / Downloads: 58)
2) Extract that in your QB64PE folder so QB64PE can find it and make use of it.
And with that out of the way, let me start by backing up and illustrating perfectly what I was talking about back in 15.1:
Run that, and pay attention to those underscores at each font size. In particular, tell me where they are at sizes 14 through 16...
And THAT's the issue with our existing PRINT and _PRINTSTRING in a noticeable, testable, very visible way! As you can plainly see (or NOT see, in this case), PRINT and _PRINTSTRING aren't large enough (they max size at the size you specify) that it even draws those underscores at size 15 and 16. It just cuts them off and gives you a basic blank space where they exist.
.
.
.
Now, when folks ask, "Should I go back and redo all my old code?", I have one simple question for them:
"Do you see that problem with your existing code and fonts?"
If not, then I wouldn't worry over it. What you have works. Going back and redoing old stuff is a PITA. Why break what's working??
I'm certainly not in a rush to go back and redo all my old stuff to swap over from PRINT and _PRINTSTRING. I just plan on making use of _UPRINTSTRING in the future, when I make use of any custom fonts.
And with that basic recap out of the way, let's take a look at the actual syntax and how to use this command:
QB64PE Wiki Link: https://qb64phoenix.com/qb64wiki/index.php/UPRINTSTRING
Format Syntax: _UPRINTSTRING (column, row), textExpression$[, maxWidth&][, utfEncoding&][, fontHandle&]
And for those who want to compare, here's the PRINSTSTRING pages/info:
QB64PE Wiki Link: https://qb64phoenix.com/qb64wiki/index.php/PRINTSTRING
Format Syntax: _PRINTSTRING(column, row), textExpression$[, imageHandle&]
As you can see, _UPRINTSTRING does everything that PRINTSTRING does, plus more -- with the exception of [,&imageHandle]....
...and, to be 100% honest, we simply overlooked adding [,imageHandle] as an optional parameter to _UPRINTSTRING. Expect to see it added as an option to the command, in an upcoming update.
(Hey, what can I say?? We're human too! We overlook stuff. It's why posts and topics such as these KotD are so important -- they help make certain we double, then triple back to our work -- and then go back to it one more time! We miss stuff. We admit it. We fit it. Everyone prospers and we move on!
)
And with all that said, let me break down that syntax for us:
_UPRINTSTRING (column, row), textExpression$[, maxWidth&][, utfEncoding&][, fontHandle&][,imageHandle&]
Note the red [,imageHandle&] parameter in there. It doesn't exist yet in our language, but will probably with the next update, so I'm going to go ahead and include it in here first.
_UPRINTSTRING <-- essential name of the command
(column, row) <-- exact same coordinate system that we currently use with _PRINTSTRING. (Though the wiki should read (x, y) here, in my opinion.)
textExpression$ <-- the text that we want to print. Works exactly the same as _PRINTSTRING (though we don't clip off characters like Print and PrintString do.)
So, for most folks, this is all they're going to need -- and it works exactly like _PRINTSTRING does. The only difference is the font height/width is going to be a little wider/taller, but if you're used to using _PRINTSTRING, you should be able to adapt to _UUPRINTSTRING with zero issues.
Just get in the habit of typing that U between the underscore and the P, and for most folks, this command -- by itself -- should work with no issues for them.
(Keeping in mind that I continue to mention that we'll print a little taller/wider to the screen. I'll cover the new commands to deal with those in the next few days with _UFontHeight, _UPrintWidth, and such.)
So basic functionality for this command shouldn't be anything new for folks. At its core, it's simply a FIX (at least Steve will always consider this a FIX) for a serious problem with Print and PrintString, without breaking folks existing code. The basic syntax is the same. Usage is the same. It's just got an U in front of it to distingish it from the old command.
That, and while working on adding this command, we added in some missing functionality with those new, optional, parameters that I haven't covered yet. Let me get to them now:
[, maxWidth&] <-- This new parameter lets you set a max width for what you want to print. Like PrintString, _UPrintString does *NOT* do any word wrap, page scrolling, or printing down on the next line. Send it a line of 1000 characters, for a screen which can only hold 80, and it'll print 1000 characters....
...the only problem is it'll only print 80 on the given line, with 920 characters being "printed" and lost off-screen!!
Set the maxWidth& here, and the command will quit once it reaches the width you specify, which can help speed up your programs and keep things organized neatly for you.
[, utfEncoding&] <-- Now this parameter is one more for "Advanced Users". It lets you specify if the text$ you're sending it is going to be ASC, or UTF-8, UTF-16, or UTF-32.
Note that the IDE only supports ASC encoding, so it's going to be hard to type the unicode into the IDE. This parameter will probably only be of use with external text files.
Honestly, I imagine 99.9999% of the user-base can just safely skip this parameter, in most cases. IF *YOU* happen to be the one guy who needs something like this, then you already know it. If you're uncertain, then just skip this parameter and move on to the next one.
[, fontHandle&] <-- A new, optional paramater so you don't have to _FONT this and _FONT that, all the dang time. Supply the loaded handle here, use it, and don't change what you already have set for your screen. In my personal opinion, this is brilliant!!
And that's it, in a nutshell!
The new command works basically with the same syntax as the old command. The only difference really being:
1) The font rendered is going to be a little wider and taller.
2) That font isn't going to get cut off like it did with the old statements. It'll look crisper, prettier, and overall nicer.
3) There's a few extra parameters added as options to this new statement, just for ease and quality of life.
For most folks, if they've ever used _PrintString in the past, swapping over to _UPrintString should be just 100% intuitive for them.
If anyone has questions, concerns, or comments, feel free to ask below. I'll cover them ASAP for everyone.
1) Grab the following font for use with examples/discussion:
DejaVuSansMono.7z (Size: 159.23 KB / Downloads: 58)
2) Extract that in your QB64PE folder so QB64PE can find it and make use of it.
And with that out of the way, let me start by backing up and illustrating perfectly what I was talking about back in 15.1:
Code: (Select All)
SCREEN _NEWIMAGE(1000, 600, 32)
Font$ = "DejaVuSansMono.ttf"
LargeFont = _LOADFONT(Font$, 40, "monospace")
Text$ = "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789______"
_FONT LargeFont
FOR i = 14 TO 24
CLS
Font = _LOADFONT(Font$, i, "monospace")
_UPRINTSTRING (100, 25), "Deja Vu Sans Mono Font, Size" + STR$(i)
_UPRINTSTRING (0, 100), " Print :"
_UPRINTSTRING (0, 200), "_PrintString :"
_UPRINTSTRING (0, 300), "_UPrintString:"
_FONT Font
LOCATE 150 \ _FONTHEIGHT, 350 \ _FONTWIDTH: PRINT Text$
_PRINTSTRING (350, 230), Text$
_UPRINTSTRING (350, 330), Text$
_FONT LargeFont
_FREEFONT Font
SLEEP
NEXT
Run that, and pay attention to those underscores at each font size. In particular, tell me where they are at sizes 14 through 16...
And THAT's the issue with our existing PRINT and _PRINTSTRING in a noticeable, testable, very visible way! As you can plainly see (or NOT see, in this case), PRINT and _PRINTSTRING aren't large enough (they max size at the size you specify) that it even draws those underscores at size 15 and 16. It just cuts them off and gives you a basic blank space where they exist.
.
.
.
Now, when folks ask, "Should I go back and redo all my old code?", I have one simple question for them:
"Do you see that problem with your existing code and fonts?"
If not, then I wouldn't worry over it. What you have works. Going back and redoing old stuff is a PITA. Why break what's working??
I'm certainly not in a rush to go back and redo all my old stuff to swap over from PRINT and _PRINTSTRING. I just plan on making use of _UPRINTSTRING in the future, when I make use of any custom fonts.
And with that basic recap out of the way, let's take a look at the actual syntax and how to use this command:
QB64PE Wiki Link: https://qb64phoenix.com/qb64wiki/index.php/UPRINTSTRING
Format Syntax: _UPRINTSTRING (column, row), textExpression$[, maxWidth&][, utfEncoding&][, fontHandle&]
And for those who want to compare, here's the PRINSTSTRING pages/info:
QB64PE Wiki Link: https://qb64phoenix.com/qb64wiki/index.php/PRINTSTRING
Format Syntax: _PRINTSTRING(column, row), textExpression$[, imageHandle&]
As you can see, _UPRINTSTRING does everything that PRINTSTRING does, plus more -- with the exception of [,&imageHandle]....
...and, to be 100% honest, we simply overlooked adding [,imageHandle] as an optional parameter to _UPRINTSTRING. Expect to see it added as an option to the command, in an upcoming update.
(Hey, what can I say?? We're human too! We overlook stuff. It's why posts and topics such as these KotD are so important -- they help make certain we double, then triple back to our work -- and then go back to it one more time! We miss stuff. We admit it. We fit it. Everyone prospers and we move on!
)And with all that said, let me break down that syntax for us:
_UPRINTSTRING (column, row), textExpression$[, maxWidth&][, utfEncoding&][, fontHandle&][,imageHandle&]
Note the red [,imageHandle&] parameter in there. It doesn't exist yet in our language, but will probably with the next update, so I'm going to go ahead and include it in here first.
_UPRINTSTRING <-- essential name of the command
(column, row) <-- exact same coordinate system that we currently use with _PRINTSTRING. (Though the wiki should read (x, y) here, in my opinion.)
textExpression$ <-- the text that we want to print. Works exactly the same as _PRINTSTRING (though we don't clip off characters like Print and PrintString do.)
So, for most folks, this is all they're going to need -- and it works exactly like _PRINTSTRING does. The only difference is the font height/width is going to be a little wider/taller, but if you're used to using _PRINTSTRING, you should be able to adapt to _UUPRINTSTRING with zero issues.
Just get in the habit of typing that U between the underscore and the P, and for most folks, this command -- by itself -- should work with no issues for them.
(Keeping in mind that I continue to mention that we'll print a little taller/wider to the screen. I'll cover the new commands to deal with those in the next few days with _UFontHeight, _UPrintWidth, and such.)
So basic functionality for this command shouldn't be anything new for folks. At its core, it's simply a FIX (at least Steve will always consider this a FIX) for a serious problem with Print and PrintString, without breaking folks existing code. The basic syntax is the same. Usage is the same. It's just got an U in front of it to distingish it from the old command.
That, and while working on adding this command, we added in some missing functionality with those new, optional, parameters that I haven't covered yet. Let me get to them now:
[, maxWidth&] <-- This new parameter lets you set a max width for what you want to print. Like PrintString, _UPrintString does *NOT* do any word wrap, page scrolling, or printing down on the next line. Send it a line of 1000 characters, for a screen which can only hold 80, and it'll print 1000 characters....
...the only problem is it'll only print 80 on the given line, with 920 characters being "printed" and lost off-screen!!
Set the maxWidth& here, and the command will quit once it reaches the width you specify, which can help speed up your programs and keep things organized neatly for you.
[, utfEncoding&] <-- Now this parameter is one more for "Advanced Users". It lets you specify if the text$ you're sending it is going to be ASC, or UTF-8, UTF-16, or UTF-32.
Note that the IDE only supports ASC encoding, so it's going to be hard to type the unicode into the IDE. This parameter will probably only be of use with external text files.
Honestly, I imagine 99.9999% of the user-base can just safely skip this parameter, in most cases. IF *YOU* happen to be the one guy who needs something like this, then you already know it. If you're uncertain, then just skip this parameter and move on to the next one.
[, fontHandle&] <-- A new, optional paramater so you don't have to _FONT this and _FONT that, all the dang time. Supply the loaded handle here, use it, and don't change what you already have set for your screen. In my personal opinion, this is brilliant!!
And that's it, in a nutshell!
The new command works basically with the same syntax as the old command. The only difference really being:
1) The font rendered is going to be a little wider and taller.
2) That font isn't going to get cut off like it did with the old statements. It'll look crisper, prettier, and overall nicer.
3) There's a few extra parameters added as options to this new statement, just for ease and quality of life.
For most folks, if they've ever used _PrintString in the past, swapping over to _UPrintString should be just 100% intuitive for them.
If anyone has questions, concerns, or comments, feel free to ask below. I'll cover them ASAP for everyone.
