Using Chr() With Val()

[heartbone]

Then the funny behavior that I encountered last week is not a Linux quirk, but rather a Windows® bug.
In order to support this functionality,
░░▒▒▓▓██ »──► To enter a smiley ☺ (☻) (☹) press Alt+1 (Alt+2) (Alt+3)."
I inserted some Linux compiled only code similar to

Code: Select all

X$= Chr(9785)
MessageRequester("SOFTWARE",X$)
Debug X$

Which displays properly when executed in the Linux requester.
Now that I grok the font difference in the debug window, it makes me think this Chr() behavior is a Windows® only problem.
I wonder which font is used in the Linux MessageRequester() function to have that character defined?

[mestnyi]

Sorry if out of topic.
How can I get the numbers on the letter such as "A" = 65 tried that still get the letter Debug 'A'

[luis]

Code: Select all

Debug Asc("A") ; 65 for a string
Debug 'A' ; 65 for a char

[BasicallyPure]

I apologize for posting a wrong solution above.
My mistake was accepting chris319's original comment that Chr($2046) should be 'F'.
If I had thought about it more I would have realized that 'F' could not be correct.
In my defense though, it did give the result he asked for.

From all of the comments it was clear that the IDE settings are vital to getting the expected result.
To help me understand better I performed some simple experiments and here are the results.
It looks like IDE configuration #3 gives the correct results.
I will leave it to others to decide if there is any bug here or not.

Code: Select all

; #1 IDE configuration:
; Compiler/Compiler Options/Create unicode executable (unchecked)
; File/File format/Encoding: Plane Text

Debug Chr($2046)        ; result = F
Debug Chr(Val("$2046")) ; result = F

Code: Select all

; #2 IDE configuration:
; Compiler/Compiler Options/Create unicode executable (checked)
; File/File format/Encoding: Plane Text

Debug Chr($2046)        ; result = F
Debug Chr(Val("$2046")) ; result = ⁆

Code: Select all

; #3 IDE configuration:
; Compiler/Compiler Options/Create unicode executable (checked)
; File/File format/Encoding: Utf8

Debug Chr($2046)        ; result = ⁆
Debug Chr(Val("$2046")) ; result = ⁆

Code: Select all

; #4 IDE configuration:
; Compiler/Compiler Options/Create unicode executable (unchecked)
; File/File format/Encoding: Utf8

Debug Chr($2046)        ; result = F
Debug Chr(Val("$2046")) ; result = F

[heartbone]

UBUNTU 14.04 x86 (using default font for debug output)

Code: Select all

; #3 IDE configuration:
; Compiler/Compiler Options/Create unicode executable (checked)
; File/F&ile format/Encoding: Utf8
Debug Chr($2046)        ; result = "" (or blanks I'm not sure which)
Debug Chr(Val("$2046")) ; result = ""

However ,

Code: Select all

MessageRequester("warez",Chr($2046))
MessageRequester("warez",Chr(Val("$2046")))

agrees with your #3 results.

[Little John]

So this seems to be a limitation of Debug, or of the font that Debug uses on your or my system.
A Unicode character can only be displayed, if the used font has a glyph for it.
In many fonts, glyphs for several Unicode characters are missing.

Is there even a suitable replacement font available to test your theory?

That's not a theory, it's called "knowledge". And yes, there are suitable fonts (see below).

Code: Select all

; #3 IDE configuration:
; Compiler/Compiler Options/Create unicode executable (checked)
; File/File format/Encoding: Utf8

Debug Chr($2046)        ; result = ⁆
Debug Chr(Val("$2046")) ; result = ⁆

This configuration is necessary to get the desired result, but not sufficient.

As I already wrote, another requirement is, that the font used by the debugger contains a glyph for Unicode code point $2046.
My personal standard font for the debugger is Consolas. With this font, I only get a result that looks like this: [?].
But when I set e.g. Lucida Sans Unicode as font for the debugger, then I see the desired result ⁆ (on Windows 7).

[heartbone]

OK BasicallyPure, in Windows® my IDE was in configuration #2, and my results were the same as yours.
When I changed the File encoding to Utf8 (config #3), again my results were the same as yours.
So it's not a Windows® bug, but an editor misconfiguration problem?

Now back in Linux, based on your post Little John, I've installed the installed Lucida Sans Unicode and pointed the degugger towards it. The new font is being used in the debugger output, but nothing makes it to the debug output from printing those glyphs.

Trying to figure out what font is used by the Linux requester, my best guess is Arial Regular 10.5 point, but I can only select Arial Regular 10 or 11. The size is really no matter, because if Arial Regular is the font family used for the Requester display, using the font does not display the unicode characters within in the debugger window.

[Little John]

On Linux Mint 17, I'm getting the desired result with BasicallyPure's setting #3 and the Monospace font (style regular) that comes with Mint for the debugger.

[heartbone]

On Linux Mint 17, I'm getting the desired result with BasicallyPure's setting #3 and the Monospace font (style regular) that comes with Mint for the debugger.

Running PB 5.22 LTS on a Linux Mint 17.1 x64 installation using the Monospace Regular 10 font as the debugger font,
seems to work identically to the PB 5.22 LTS on a UBUNTU Linux x86 installation which also has the Monospace font.
Using the IDE settings of configuration #3, the glyph characters do not show up in the debugger window, but will show in the requester.

[Danilo]

Running PB 5.22 LTS on a Linux Mint 17.1 x64 installation using the Monospace Regular 10 font as the debugger font,
seems to work identically to the PB 5.22 LTS on a UBUNTU Linux x86 installation which also has the Monospace font.
Using the IDE settings of configuration #3, the glyph characters do not show up in the debugger window, but will show in the requester.

The PB IDE and Debug Output are Unicode since PB 5.30 - PB 5.22 LTS contains the old ASCII-compiled IDE.
You could try the latest 5.3x IDE and still use the latest 5.24 LTS compiler with it.

[Little John]

The PB IDE and Debug Output are Unicode since PB 5.30 - PB 5.22 LTS contains the old ASCII-compiled IDE.

Thanks for reminding, Danilo! I had almost forgotten that.
Yes, I did all my tests here with PB 5.31.

[Danilo]

Thanks for reminding, Danilo! I had almost forgotten that.

I know, according to Buddha there is no past and no future, there is only Here and Now - a small moment
that represents the current status of energy inside the universe. Everything beside that is illusion. Memories
that are no more, or future wishes that are not reality yet.
It is easy to forget the world of the last century, after switching to latest PB Unicode version.

Big changes are coming. At work (premium car maker) we are already thinking about the
influences of 3D printers now, because somebody printed out 3D car parts to built a car himself.
Unbelievable how fast the world will change within the next few years, but it is still good to
know and remember the past, because we can learn from its mistakes and the good things it had.

[heartbone]

Thank you Danilo, for remembering the reason for the discrepancy.

The PB IDE and Debug Output are Unicode since PB 5.30 - PB 5.22 LTS contains the old ASCII-compiled IDE.
You could try the latest 5.3x IDE and still use the latest 5.24 LTS compiler with it.

Thanks for the suggestion but this debugger problem is not big enough to warrant the IDE swap and I'll wait for an acceptable release.
Just another reason it seems to resent the treatment of Linux users in the several months old 5.31 travesty, a compiler downgrade that is unacceptable by any sane measure.
The situation reminds me of this shocking interview with developers about their support of some forum members requests.

[mestnyi]

As of the string variable to read the name of the function and execute it

Code: Select all

Procedure suma2(a,b)
  ProcedureReturn a+b
EndProcedure
st$ = "suma2(3,5)"
Debug st$

[BasicallyPure]

mestnyi,
Is this what you are trying to do?

Code: Select all

Procedure suma2(a,b)
  ProcedureReturn a+b
EndProcedure
st$ = Str(suma2(3,5))
Debug st$