by Michael S. Kaplan, published on 2005/08/21 23:00 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/08/21/454340.aspx
Galit Avieli asked (via email):
My name is Galit, we are a few students from Israel working on a project using visual basic. We ran into a problem we're dealing for a few days now. Searching for a solution on the web, we saw a response you wrote in a forum that answered our problem, only it referred to Microsoft Access. We'll be more than happy if you'll help us since we can't find the answer to the problem elsewhere.
Our problem is:
I'm writing in RichTextBox under "ARIAL" font, when I switch (alt-shift) to Hebrew the font is changed to "ARIAL (Hebrew)". When I send the text to TextBox the fonts are changed to "ARIAL" and on the screen appear unreadable chars.
I would like to know how can I send the proper font name so that it would stay as "ARIAL (Hebrew)" (exactly like Microsoft WordPad is working).
That was an example, our problem is wider and refers to all languages (not just Hebrew).
Again, it would be a great help and would save months of work.
Thanks a lot and have a wonderful weekend
Galit Avieli
Israel
Unfortunately the answer is not a good one. :-(
In this particular case, at the point where you switch to the Hebrew keyboard layout, the RichEdit control underneath the RichTextBox notices the switch and changes the charset of the underlying font to Hebrew (this is also what happens in WordPad).
However, when text is sent to the control, VB does not keep it in Unicode; instead it sets the text using methods that convert it to the default system code page, which may or may not contain the characters in question. the RchEdit control is smart enough to know that the text it is being sent is not, in fact, Hebrew text. So it converts the font back.
The same problem will happen for any text that is not on the system default code page....
Unfortunately, as I talk about in Chapter 6 of my book (no longer in print, sorry!), the answer to the question "is VB <= 6.0 Unicode or not?" is not a simple one.
The answer is to not use the MS-provided RichTextBox ActiveX control; instead use one of the controls specially designed to keep Unicode text as it is, like the UniToolbox controls from Woodbury Associates, Ltd. The intrinsic controls and the VB-provided ActiveX controls for the most part will not do this.
This problem is for the most part solved with .NET, though in some cases Win9x will not see the right "Unicode" behavior due to use of underlying OS controls. But that is a subject for another post, on another day....
This post brought to you by "ג" (U+05d2, a.k.a. HEBREW LETTER GIMEL)
Yuhong Bao on 20 Apr 2010 6:16 PM:
"However, when text is sent to the control, VB does not keep it in Unicode; instead it sets the text using methods that convert it to the default system code page“
I can understand why, but why didn't they add a check for 9x vs NT and call the W functions directly if it is NT and skip that conversion?
Michael S. Kaplan on 20 Apr 2010 9:32 PM:
You are seriously asking why a team that I am not on made a decision over 12 years ago to do themselves the work that I was hired to do for Windows 9 years ago for all developers?
Yuhong Bao on 20 Apr 2010 11:45 PM:
"You are seriously asking why a team that I am not on made a decision over 12 years ago to do themselves the work that I was hired to do for Windows 9 years ago for all developers?"
Not exactly, I am asking *about* that work.
Michael S. Kaplan on 21 Apr 2010 12:36 AM:
Dude, I wasn't there.
I have talked at length about MSLU and how it works. It just was not available and they did not do something like it themselves to support calling Unicode functions. So this has already been as covered as it would be, from my point of view.
Yuhong Bao on 21 Sep 2010 4:30 PM:
BTW, I disassembled MSVBVM60.DLL and rtcShell is one function that does do this. It checks for 9x vs NT and calls CreateProcessW or CreateProcessA as appropriate.