Reputation: 235
I have built a Windows application for a touch screen using FPS Virtual Keyboard for WPF from FPS Components as my on-screen keyboard. This keyboard has a button for cycling through any keyboard languages installed in Windows, and everything works great throughout the application. The problem I'm having appears with one aspect of the application where it can link to other locally networked panels running the same application and display some info entered from the first. If the user switches the keyboard language to, say, Arabic, the string sent to the remote panels is displayed as "?????", I assume because the languages aren't matching.
Is there a relatively simple way of determining what keyboard language was used to type a string, then display it properly? From an application standpoint, the receiving panels don't need to actually change their local keyboard setting, so I would prefer to just be able to display the incoming string properly regardless of language, unless it's a requirement of Windows that the local setting change.
The panels are all running with Windows 7.
Upvotes: 0
Views: 788
Reputation: 25623
Something to remember about strings is that they don't have a "language"; a string is just a sequence of Unicode code points (i.e., characters). The "language" of the input device simply gives you a means of selecting which characters to append. Once the string is created, its contents are independent of the system/thread locale or the input device. You captured some characters, and now they're stored immutably in the string. Provided the necessary fonts are available to render the contents of the string, it should display identically on any machine running your application.
It should be simple enough to verify that the other machines have the necessary fonts installed--simply input some text in a language that's giving you problems (e.g., Arabic) and verify that it renders correctly.
Also verify that you aren't manually changing the display panel's font based on the input language. WPF's default UI font is a "composite font" that maps subsets of the Unicode character space to different font families. In other words, if part of a string contains Arabic glyphs, the corresponding segment of text will be displayed in an Arabic font. Your standard Latin glyphs will be displayed in the system font (e.g., Segoe UI), and so on. It's a very useful feature, you may lose that flexibility if you override the display panel's font.
If everything above checks out, and the text is only garbled when it is sent "over the wire", then it is most likely an encoding problem. Perhaps your networking code is doing something naive, like converting each char
in the string to a single byte
, which works fine for the standard ASCII range, but spits out garbage for the higher Unicode ranges. Make sure your strings are being encoded using a proper codec (e.g., UTF8).
Upvotes: 2