Help: Issues with the _PRINTSTRING and _INPUTBOX$ functions in QB64.

[qbfans]

During my study of QB64, I've encountered two confusing issues:

_PRINTSTRING: When used within a VIEW viewport, it doesn't seem to support relative coordinates, whereas _UPRINTSTRING works fine with them. Given how similar they are, it seems like _PRINTSTRING should also be able to use relative coordinates.

Chinese input via _INPUTBOX$: I can input Chinese characters normally in the pop-up dialog, but the returned string is garbled. Typically, a Chinese character in GBK encoding is 2 bytes, but the string returned by this function appears to be 4 bytes per character. The character encoding doesn't seem to match GBK, UTF-8, or UTF-16, making it impossible to convert and use correctly. While _MESSAGEBOX can normally display Chinese text, the characters returned by _INPUTBOX$ cannot even be displayed properly by the _MESSAGEBOX statement.

I hope to get some help from everyone. Thank you.

Code: (Select All)

Screen 12

test$ = "Hello world!"

View (10, 180)-(610, 380), , 3

_PrintString (0, 0), test$ + " _printstring"

_UPrintString (300, 0), test$ + " _uprintstring"

View

Do: k$ = InKey$: Loop Until k$ <> ""

Cls

chn$ = "QB64pe初学者"

_MessageBox "Message Correct", chn$, "info"

_MessageBox "Show InputBox Result", _InputBox$("Inputbox", "The default text displays correctly.", chn$), "warning"

[SpriggsySpriggs]

You will most likely need to do your own implementation of the input box.

[qbfans]

Thank you everyone. I don’t have the ability to rewrite complex code — I saw the InputBox implementation on the QB64.com forum, and the code was too complicated for me.
Recently, I had some time to revisit the issue of garbled characters returned by InputBox$, and I discovered there is still a pattern. My guess is that QB64 encounters issues when parsing double-byte Chinese characters during encoding conversion. The specific pattern is as follows:

When X ≥ 192 (0xC0):
First byte = 195, second byte = 128 + (X - 192)

When 128 ≤ X < 192:
First byte = 194, second byte = X

Reverse conversion (fix function):
If the first byte = 195:
Original GBK byte = 192 + (second byte - 128)
If the first byte = 194:
Original GBK byte = second byte

Since the mapping is this simple, handling it becomes straightforward.

Code: (Select All)

Function FixByte% (b1 As _Unsigned _Byte, b2 As _Unsigned _Byte)

    If b1 = 195 Then FixByte = 192 + (b2 - 128) ' C3 prefix

    If b1 = 194 Then FixByte = b2              ' C2 prefix

End Function

Code: (Select All)

$Console:Only

Function FixByte% (b1 As _Unsigned _Byte, b2 As _Unsigned _Byte)

    If b1 = 195 Then FixByte = 192 + (b2 - 128) ' C3前缀

    If b1 = 194 Then FixByte = b2 ' C2前缀

End Function

Print

Dim As String a, a1, fixa: a1 = "中"

Print "a and a1 are the same Chinese character-->'中'"

Print "a1 ascii code:          "; Asc(a1, 1); "  "; Asc(a1, 2)

Print "a2(Inputbox) ASCII code:";

a = _InputBox$("", "input", "中")

For i = 1 To 4

    b = Asc(a, i)

    Print b; "  ";

Next i

Print: Print

'now fix it

Dim As _Unsigned _Byte b1, b2

Dim fixtmp As Integer

Dim As String fixchr: fixchr = ""

Print "Now,fix it."

Print "Process two bytes at a time, then concatenate them to restore."

Print "AFter fix ASCII code:  ";

For i = 1 To 4 Step 2

    b1 = Asc(a, i)

    b2 = Asc(a, i + 1)

    fixtmp = FixByte(b1, b2)

    Print fixtmp; "    ";

    fixchr = fixchr + Chr$(fixtmp)

Next

Print fixchr

Sleep

End

The example below is just a simple demonstration — it takes a straightforward approach. In practice, more checks and handling may be needed.
This code probably won’t be testable or useful for our Latin-alphabet friends, but I’m posting it here for anyone who might need it.
Additionally, I believe this is a bug in the function itself. I hope the development team can fix it and improve this otherwise very useful built-in function.