Bugs, Mr. Rico!

Recompiling my test app with headers and LIBs that matched the DLLs I was using cleared up the really stupid problem that I was seeing last night. Now, I've managed to replicate the error that we were seeing in our big clunky MFC application in a simple Win32 console application.

With any luck, this will prompt the library writers to produce a fix.

Keep your fingers crossed. :)

Update: It seems that the library writers need to fix their documentation. Apparently, if you want to send a UTF-8 encoded string that contains non-ASCII characters, you must send through the Unicode BOM as the first string in the sequence. If that were documented anywhere, I would have done so long ago. But that appears to be secret knowledge, held only by a few.

Thud, thud, thud.

Bugs, Mr. Rico!

Recompiling my test app with headers and LIBs that matched the DLLs I was using cleared up the really stupid problem that I was seeing last night. Now, I've managed to replicate the error that we were seeing in our big clunky MFC application in a simple Win32 console application.

With any luck, this will prompt the library writers to produce a fix.

Keep your fingers crossed. :)

Update: It seems that the library writers need to fix their documentation. Apparently, if you want to send a UTF-8 encoded string that contains non-ASCII characters, you must send through the Unicode BOM as the first string in the sequence. If that were documented anywhere, I would have done so long ago. But that appears to be secret knowledge, held only by a few.

Thud, thud, thud.