Win10-32 chr$(9), 28 29 30 31 does not show in debug

[tsh73]

Win 10 32, found while debigging
Tried to use chr$(31) as delimiter in a string
Found that chr$(9), 28 29 30 31 does not show in debug
(and on a mainwin too, but they called unprintable anyway)
But for debugging some square (as for "missing glif") would be nice.
Besides, other characters show *something* in debug, these are - not.

please try/confirm.

EDIT on Win XP-32 all chacters are visible as rectangles
EDIT2 on Win 8.1-64 same symbol numbers are not shown
(though I see some pseudographics for ones what show instead of missing glif rectangle)

on Win 10-32


on Win XP-32


a$="A"
for i = 1 to 31
   if i<>10 and i<> 13 then
       a$=a$+chr$(i)
       print i, ">";a$;"<"
   end if
next

b$="b"+chr$(28)+chr$(29)+chr$(30)+chr$(31)+"B"
print ">";b$;"<", len(b$)

c$="c"+chr$(9)+chr$(9)+"C"
print ">";c$;"<", len(c$)

input "press Enter";d$



[Brandon Parker]

I think some of what you see might be due to how the text window and/or operating system interpret the non-printable characters.

Since they are "non-printable" characters, is it really an issue?

Try running this in LB5-352; I get different results there as well.



{:0)

Brandon Parker

[tsh73]

I was debugging program where
a$=chr$(31)+"key"+chr$(31)
And in debug window, a$ shows just as "key".
That's an issue.

[Rod]

Well control character 31 is Unit Separator. Meant to be invisible but to do its job. Getting Liberty to "show" something for every character value surely cuts across protocol. What should it do for backspace?

We need to know they are in a string, len() we need to be able to know what they are asc(), but it entirely depends on the display object what we see. For text display we should see "" zilch. But ide/debug should be consistent.

[Carl Gundel]

Apr 23, 2021 9:34:55 GMT -5 tsh73 said:

I was debugging program where
a$=chr$(31)+"key"+chr$(31)
And in debug window, a$ shows just as "key".
That's an issue.

I think something could be done for LB5.