Centering text inside char bax

[SMcNeill]

@mnrvovrc:  I'm not into fancy dialogs, but now I have a new word to "investulate": $noprefix. Thanks for your input.

If you want my honest opinion, just forget that NoPrefix even exists.  When one command alters or invalidates other commands for you, it's one that should often just be ignored.  Is it really that much extra work to type an underscore for the QB64 specific keywords?

Two things to watch for with NOPrefix:

1) Various commands and such fall into conflict and require code changes just by popping it into your code.

$COLOR:32
CLS Red
PRINT _Red(4)

Take the above into consideration.  As is, it works just peachy fine.  You can use the color CONST Red with your program, as well as the command _Red to get back red levels from a color on the screen.

Add a $NoPrefix to that, however, and you now have Red being a command (where it was _Red before), and that conflicts with Red as the color.  Your code is now going to glitch out until you go in and alter all references to Red (the color) so they no longer conflict with Red (the command).   This also applies to Green and Blue as well...

2) Code you write with NoPrefix today may not compile without changes tomorrow.

Let's say you write a program and use a variable called Foo.  DIM Foo AS LONG...

Now, 2 years from now, we add a new command into the language:  _FOO.   

What happens to your old code??  It's now got to be changed to compile with new versions of QB64 with $NoPrefix because Foo (would be the unprefixed version of _Foo), and you can't make your variable the same as a reserved function.

---

There was a reason why Galleon reserved that underscore for use with QB64-specific keywords, and why user's can't create any variables or CONST with just a single leading underscore to them.  Honestly, why the old team decided to even add $NoPrefix to the language is beyond me.  It breaks existing commands with Red, Green, Blue and $Color, and it has the potential to break future compatibility with anything an user writes.  And for what??  Just to save typing a leading underscore for the QB64 specific keywords??

It's not worth the drawbacks in using it, in my opinion.

[mnrvovrfc]

My instruction is for someone who posted code like bplus did on this thread. Then later someone else joins the forum, copypastas the code, runs it and then cries into this forum claiming there is a "major bug". Because the code supplied from the forum became a reserved word without the leading underscore. Because that user decided the underscore is "too much" typing and therefore he/she will use $NOPREFIX to do something about it.

Blame the contributor, I guess. (shrugs)

The thing is that bplus wrote an useful subprogram that somebody would wish to incorporate into his/her program. However if he/she also plans to use the commands introduced in QB64PE v3.5, which come from the Tinydialogs then the subprogram's name in the forum contribution should be changed.

Before someone else says, "Oh now I have to look it up in the Wiki to see if it's not already a variable or command or function!" then keep in mind that adding features to our brand of BASIC requires a few trade-offs, it's growth that cannot be controlled. In this example, "MessageBox" is used an awful lot in the Win32 API world. It was probably picked in dozens of tool kits that we don't know about, done by other people using QuickBASIC, QBasic and any version of QB64, and other BASICs as well. But suddenly in QB64PE it becomes something the compiler flags, for example the subprogram presented here because it expects three strings as parameters!

[SMcNeill]

That's why I mentioned it's best to just forget that $NoPrefix exists.  Even in Bplus's example here, he has a Sub called MessageBox.  By itself, it doesn't conflict with anything in QB64.  Once $NoPrefix is added into the mix though, it errors out as there is a command called _MessageBox (and the no prefix version of it would be MessageBox).

$NoPrefix is just asking to open a can of worms to make your code hard to maintain and preserve for longevity's sake.  For ages, I've had a SaveImage library which I've shared for folks to use.  If QB64 adds a _SaveImage command in a year or so, there wouldn't be any issues or compatibility problems as there'd be a difference in the underscored and reserved QB64 command, verses my personal routine.   Once $NoPrefix enters the situation, however, then all sorts of problems poop up, requiring a rewrite of something to resolve the conflict.

Personally, I'm just never going to use $NoPrefix, nor ever code with it, and if there's an incompatibility with one of my routines or libraries due to it, I'm leaving it up to the end-user of that library to sort it out and deal with it.  $NoPrefix compatibility isn't anywhere on my list of things of even considering when coding.  The underscores are there in QB64 keywords to prevent any issues from arising like such, and if someone wants to sidestep those protections just to save typing a bit, then I feel its on them to sort out the conflict and not me. 

[OldMoses]

I tried $NoPrefix once on a rather large program, I didn't like it and changed it back. It was a bit like picking fly crap out of pepper to put all those underscores back in, but in light of Steve's concerns I feel justified now. I can't say that I ever specifically noticed any of those issues, but I still preferred being able to recognize the command set at a glance. There's also things like the old WIDTH and the new _WIDTH to consider.

[PhilOfPerth]

Well, that's saved me a lot of investulation time! I won't be using _NoPrefix. 
Not that I would have anyway, I guess, given my level of programming skill.
Thanks for the advice.