Nulls strings BUG?

[Jon Richfield]

Trying to enter a string of nulls seems to do all sorts of nasty stuff to the editor.
How did I get the following text into the editor? I wrote it into a .BAS file, then opened the file with QB64.

OPEN "C:\TEMP\lowvals.bas" FOR OUTPUT AS #1
PRINT #1, "   CONST NULL = " + CHR$(34) + CHR$(0) + CHR$(34)
PRINT #1, "   CONST NULLS = " + CHR$(34) + STRING$(8, CHR$(0)) + CHR$(34)
PRINT #1, "   N$ = NULLS"
PRINT #1, "   PRINT N$"
CLOSE
END

OK?
Now run that file and it should create a BAS file that works, more or less.
Now, run that BAS file and see that it works, even though those strings contain nulls, not spaces.
So copy one of those const statements and paste it into that same program, or another , say with 4 nulls instead of 8. And see what happens.

If you persist in trying to make it work with your mouse or by using ALT[0], funny things happen, like switching the mouse buttons etc, and your not being able to close the string's quotes.

Am I doing something wrong, or is there an outstanding correction?

[Qwerkey]

Jon, I believe that you have run into the difficulties which CONST is known to have.  Use of CONST where some kind of "extra" manipulation is involved often seems to lead to problems.  So CONST Phrase = "This Works" and CONST Phrase = CHR$(30) will be OK, but CONST Phrase =  STRING$(10,13) may fail.  The experts will be with you shortly on this, I have no doubt.
Are you sure that NULL and NULLS have to be CONST?  If you leave them as "ordinary" strings, things will work (NULL and NULLS have to be DIMed as STRING).

[FellippeHeitor]

Don't store chr$(0) as a literal. You are creating a text file, not a binary file. Keep using chr$(0) to generate fill for your variable contents, and make it a DIM SHARED variable instead of a const, like Richard indicated above.

[Jon Richfield]

Yes, I certainly am creating a character file (though not necessarily printable characters), but that does not mean that being able to specify low-values is not a useful facility in dealing with sequenced files in matching etc. In this it corresponds to High-values for end of file or end of procedure facilities, instead of say, checking for end of file or end of string every time.

In the same program I am in fact using high values (X"FF") by entering "[alt][255]" as someone recently pointed out helpfully. This alt-character facility seems to work for everything but X"00", which I then had intended to use, but have found the editor unable to handle.

Now, there still are options I can manage, such as using a hex editor on my Basic source file, but that seems an eccentric measure to have recourse to in such a powerful facility as QB64. I thought that the developers would like to know of the bug. If not, OK, I'll manage. Thanks anyway.

[FellippeHeitor]

Code: QB64: [Select]

1. DIM SHARED NULL AS STRING
2. DIM SHARED NULLS AS STRING
3.  
4. NULL = CHR$(0)
5. NULLS = STRING$(8, 0)
6.  
7. N$ = NULLS
8. PRINT N$

That's our point.

Any other approach will give you trouble.