Question about the ASCII chart in Help.

[Pete]

I noticed that the null characters, 0 and 255, react differently on mouse-over. 255 flashes 255, but the first character block, for CHR$(0), does not flash a zero value. It should, shouldn't it?

Pete

[FellippeHeitor]

For some reason Steve deliberately decided not to show a 0, so we'll have to wait for his reasons on this one (ASCII box is his work):

Code: QB64: [Select]

1. 'From source/ide/ide_methods.bas, starting at line 14202:
2.         IF num = 0 THEN
3.             text$ = ""
4.         ELSE
5.             flashcounter = flashcounter + 1
6.             IF flashcounter > 30 THEN
7.                 COLOR _RGB32(255, 255, 255), _RGB(0, 0, 170)
8.                 text$ = CHR$(num)
9.                 IF LEN(text$) = 1 THEN text$ = " " + text$ + " "
10.             ELSE
11.                 COLOR _RGB32(255, 255, 255), _RGB(0, 0, 170)
12.                 text$ = RTRIM$(LTRIM$(STR$(num)))
13.             END IF
14.         END IF

Likely because you can't insert a CHR$(0) there anyway.

[SMcNeill]

Likely because you can't insert a CHR$(0) there anyway.

Aye. 

Honestly, it should probably also not work with CHR$(255).  The possibility of the user ending up with uncompileable, unreadable, unfixable code goes up dramatically once you start adding extra, invisible, non-spaces into it.  If you just want a space, use CHR$(32) and avoid those extra blank spots which might end up becoming a huge PITA for you.

[RhoSigma]

According to CP437 mapping, CHR$(255) is a hard, or non-break space (  in HTML) and therefor it should be allowed to be entered at least within string literals. In fact I use it just for the non-break purpose in several programs (of course, in strings only) and it never made the programs uncompileable.

[Raven_Singularity]

I used to use Alt+255 on folder names in DOS, to make them appear to be locked:

"MY_DIR<Alt+255>"

In a DIR listing it appeared to just be called "MY_DIR" but you couldn't CD into that dir.  Quite effective at keeping average DOS users out of my files!  :-)

Anyhow, CHR$(255) is a real character and should be allowed in the IDE and apps.  CHR$(0) on the other hand is not a printable character.

[Pete]

I've used CHR$(0) in my word processing apps.

Pete

[Raven_Singularity]

For what purpose?  It's a NUL byte, it is not meant to display anything, ever.

[Pete]

It takes up space just like CHR$(32) "space" or CHR$(255).

Code: QB64: [Select]

1. x$ = STRING$(10, 0)
2. PRINT "|"; x$; "|"

As such, if you read a line of text, you can have CHR$(0) or CHR$(255) mark the text. For example, it could be used to highlight text, etc. It could be used to hold the place of a cursor during a cut/paste operation. Lots of possibilities.

Pete

[Cobalt]

I use both 0 and 255 for drive wiping. as it sets the bits either all 0 or all 1 and destroys all information.

[Raven_Singularity]

"It takes up space just like CHR$(32) "space" or CHR$(255)."

I know that the NUL byte does not display in Unix/Linux terminals, and I'm 95% sure it doesn't display in standard DOS terminals.  The NUL byte normally gets eaten, non-displaying, and the remaining characters shift to the left.  In DOS, CHR$(0) is not not the same as CHR$(32) or CHR$(255), in that both of those are printable characters.

[Pete]

I've never cared about x-platform compatibility, so I had no idea the code I posted would get eaten in Linux.

So on your Linux computer, assuming you have one, if you run...

x$ = STRING$(10, 0): PRINT "|"; x$; "|"

Do you get || or |           | as the result?

Well I'm not a Windows fan, by any stretch of the imagination, to me, Linux is hobby onto itself. As such, it is a giant waste of time to for me to add another hobby just to do a hobby I currently enjoy.

I haven't been in pure DOS since 1980-something.

One sad future possibility is, if MS ends up as app only software and computer leasing instead of ownership, I'll be either grudgingly switching to Linux, or saying bye-bye forever to programming. I think I'm positioned pretty well, age considered, and if I do ever switch to Linux, and I find out the code I posted above does not display with 10 spaces between those bars, I'll remember this post.

Pete

[Raven_Singularity]

To be clear, I am not stating that QB64 output eats NUL bytes, I'm saying that a normal DOS or Unix terminal eats NUL bytes.  As far as I know, QB64 emulates its own terminal outputs and does not use standard DOS, Unix, Mac, or Windows terminal outputs.

In terms of how QB64 should behave, it should respect that CHR$(0) is not meant to be a printable character in Unix, DOS, or QuickBASIC.  CHR$(255) is meant to be a printable character, which is visually the same as a space character, but with a different character number so it isn't actually a space.  In the original QBASIC, INKEY$ displays special keys as a NUL byte + another byte.  The NUL part was never displayable, which was a touch confusing when first learning INKEY$, as it appeared to be returning a single character when pressing arrows or F-keys or whatever.  Had to use LEN() on it to make any sense of it!


I just tried this command on a GNU+Linux terminal to confirm:

Code: QB64: [Select]

1. printf '[\x00]\n'
2.  
3. []

The NUL byte gets eaten, all that is output is the two braces by themselves.

Code: QB64: [Select]

1. printf '[\x00]\n' | wc --bytes
2.  
3. 4

This returns "4" as expected, the two square bracket bytes, the NUL byte, and the Unix newline byte.  The NUL byte is there, but it is not displayed.


Please note that there are tons of non-display characters in terminals, such as ANSI codes.  There are also a lot of special terminal characters, such as the TAB character CHR$(9) / Ctrl+K which brings the cursor to the next horizontal tab stop, or BEL character CHR$(7) / Ctrl+G which tells the PC speaker to issue a beep sound.


Speaking of which, does the QB64 emulated terminal support ANSI colour codes?

QuickBASIC used the standard DOS terminal for output, so it supported ANSI codes if your version of DOS supported ANSI codes.

I just checked, and QB64 does not support ANSI codes.  It displays the ESC character CHR$(27) as a left-pointing arrow.

[Pete]

Well, my guess is my code will print the same on a Linux computer running QB64. Anyway, here is an interesting wiki page you may want to view, to print control characters in QB64...

http://www.qb64.org/wiki/CONTROLCHR