Using offset 3380 gives weird characters in FS

[Jasper Bussemaker]

Hi Pete,

When I use the offset 3380 (and 32FA) to write text to FS to be displayed, it only displays some weird characters.

I'm using VB6, and in the readme.txt of the VB6 SDK, they say you might need to convert the string from unicode to ASCII.

If I convert the string I am sending, but also if I do not convert it, FS displays weird characters (see below).

This is my code:

Dim strMessage As String, strMessageB As String, i As Double, dwResult As Long, lACARS As Long
If Len(strMessage) > 127 Then strMessage = Mid(strMessage, 1, 127)
For i = 1 To Len(strMessage)
    strMessageB = strMessageB & ChrB(Asc(Mid(strMessage, i, 1)))
Next i
strMessageB = strMessageB & Chr(0)
strMessage = strMessage & Chr(0)

Call FSUIPC_Write(&H3380, Len(strMessage), VarPtr(strMessage), dwResult)
If FSUIPC_Process(dwResult) Then
ElseIf dwResult <> 0 Then GoTo NotOpen
End If

lACARS = 10
Call FSUIPC_Write(&H32FA, 2, VarPtr(lACARS), dwResult)
If FSUIPC_Process(dwResult) Then
ElseIf dwResult <> 0 Then GoTo NotOpen
End If

It first checks the length of the string, then converts strMessage to ASCII in strMessageB.

Finally it adds a null terminator to both of the strings.

Then when I test it, with both strMessage and strMessageB it displays those weird characters.

What I noted was that when I sent strMessageB (the converted one) to FS, it displayed twice as much chars as when I sent strMessage.

I think this is weird, because strMessageB is the converted one which only uses 1 byte per char whereas strMessage uses 2 bytes per char (unicode).

Note: the part to convert the string was literally copied from the readme.txt file of the VB6 SDK.

I hope you can spot and solve the error!

Greetings,

Jasper

[Pete Dowson]

When I use the offset 3380 (and 32FA) to write text to FS to be displayed, it only displays some weird characters.

I'm using VB6, and in the readme.txt of the VB6 SDK, they say you might need to convert the string from unicode to ASCII.

If I convert the string I am sending, but also if I do not convert it, FS displays weird characters (see below).

Sorry, I don't know enough about VB to identify your problem. Someone else will need to help.

This is my code:

Well, I may well be wrong, but it looks like you convert to ASCII then back to whatever default character code you have in VB:

ChrB(Asc(Mid(strMessage, i, 1)))

which seems to defeat the object. Try using a byte array and copying the Asc values into that instead.

Also, although you take all that trouble to build a string in strMessageB, you then write strMessage to 3380.

Finally, it is very very inefficient to do multiple FSUIPC_Process calls, each one causing a process switch. Just to all the reads and writes you want to do in each cycle with one Process call at the end. In this example, providing you write 32FA after writing 3380 it will work with one Process call.

What I noted was that when I sent strMessageB (the converted one) to FS, it displayed twice as much chars as when I sent strMessage.

Do you clear strMessageB to nothing first?

I think this is weird, because strMessageB is the converted one which only uses 1 byte per char whereas strMessage uses 2 bytes per char (unicode).

Are you sure? Doesn't "Chr" convert it to whatever character system in use? Or is "ChrB" a special variant?

Note: the part to convert the string was literally copied from the readme.txt file of the VB6 SDK.

Strange, then. Who wrote that? Does the example work?

I hope you can spot and solve the error!

Have you tried using the Logging facilities in FSUIPC to see what it is being written? I'm sure it will be easy to work it out when you know that! That's what the logging facilities are for.

Regards

Pete

[Jasper Bussemaker]

Try using a byte array and copying the Asc values into that instead.

Good one :)

Also, although you take all that trouble to build a string in strMessageB, you then write strMessage to 3380.

That's because in the code I copied I tested strMessage, it's just because I was testing the various results... ;)

Have you tried using the Logging facilities in FSUIPC to see what it is being written? I'm sure it will be easy to work it out when you know that! That's what the logging facilities are for.

Let's try this one :)

I'll keep you updated!

Greetings,

Jasper

[Jasper Bussemaker]

Ok now I have this code:

Dim strMessage As String, strMessageB As String, i As Double, dwResult As Long, lACARS As Long, b() As Byte, tmp As Long
strMessage = Text
If Len(strMessage) > 127 Then strMessage = Mid(strMessage, 1, 127)
For i = 1 To Len(strMessage)
    strMessageB = strMessageB & ChrB(Asc(Mid(strMessage, i, 1)))
Next i
strMessageB = strMessageB & Chr(0)
b() = strMessageB

Dim CurrOffset As Long, CurrAsc As Long
For i = 0 To UBound(b)
    CurrOffset = &H3380 + i
    CurrAsc = b(i)
    Call FSUIPC_Write(CurrOffset, 1, VarPtr(CurrAsc), dwResult)
Next
lACARS = -1
Call FSUIPC_Write(&H32FA, 2, VarPtr(lACARS), dwResult)
If FSUIPC_Process(dwResult) Then
ElseIf dwResult <> 0 Then GoTo NotOpen
End If

And it works!

The problem was that if I put strMessage instead of strMessageB into the byte array (b()) it would write between every char a 0 char and FS doesn't understand that.

But it works!!

Thanks for your help :)

Greetings,

Jasper

[Pete Dowson]

The problem was that if I put strMessage instead of strMessageB into the byte array (b()) it would write between every char a 0 char and FS doesn't understand that.

Yes, Unicode is a wide character coding format, 16 bits per character, with zero in the high 8 bits for normal ASCII-compatible characters. FS uses straight 8-bit ISO-extended ASCII internally.

Regards

Pete