Oh yes, with other words, the only real good solution is using UTF-8, but
unfortunately Win32::GUI doesn't support it.
From experience I know that very many computer users from Romania don't
bother to set their computers to use the romanian language, and use the
english defaults, so I need to make a program that works always, no matter
the settings of Windows.
I think I will make a few tests with WXPerl, then maybe I will pass to C#
that surely works.
Octavian
----- Original Message -----
From: "Glenn Linderman" <[EMAIL PROTECTED]>
To: "Octavian Rasnita" <[EMAIL PROTECTED]>
Cc: <perl-win32-gui-users@lists.sourceforge.net>
Sent: Friday, December 01, 2006 11:20 PM
Subject: Re: [perl-win32-gui-users] charset
On approximately 11/28/2006 8:04 PM, came the following characters from
the keyboard of Octavian Rasnita:
I have tried yoursample code. The first time it worked fine and all the
special chars were displayed correctly.
So this test was with your Regional and language options setting to use
Romanian for single-byte character type.
And it worked. So this is using some Code Page that supports Romanian.
Then I have tried to make some changes in the regional settings to see if
it works with the default settings.
So I have changed in the Regional and language options/Advanced tab to
use the English language when a program doesn't use UTF-8 but a
single-byte character type.
After doing this, only the first special char was displayed correctly,
because it can be also found in the ISO-8859-1 charset.
The other chars were replaced with non - correct characters.
And this test was with your Regional and language options setting to use
English for single-byte character type.
And it didn't work. So this is using code page 1252 (I think, or maybe
8859) that supports English and some other European languages, also known
as ISOLatin1
So, here's a global Windows question that I don't know if anyone on this
list knows the answer to, but you never know... but lack of response
probably wouldn't mean that the technique isn't possible.....
Is there a way in Windows to mark a program as using/needing a particular
Regional and language option setting?
As far as I can tell, but I am not the expert in this area, no.
http://www.microsoft.com/globaldev/handson/dev/muiapp.mspx declares loudly
that if you want to support multiple languages in one program, that you
should make it Unicode. Figure 2 explains why: that if your program's ANSI
localized language doesn't match that of the system, that you can get
inappropriate characters displayed.
Further,
http://www.microsoft.com/globaldev/handson/dev/AppCompatInMUI.mspx says:
Any non-Unicode application will be able to run only when the system
locale (also called “Language for non-Unicode Programs” on XP) is set to
match the application’s language.
and
It normally makes sense to have your program’s UI language in sync with
the system UI, you can call /GetUserDefaultUILanguage/ to know the
current user’s UI language and switch your applications’ based on it.
So it does appear that it is a limitation of the design of Windows, that
even though Windows itself supports Unicode, and can translate all the
various code pages to and from Unicode (consistently, when all the
characters benig converted are in the code page of interest), that there
is no support for the code page to be specified on a per-program basis.
On the other hand, it is quite possible that some other page in the
Windows documentation will contradict these pages, and give a solution.
But I wouldn't hold my breath.
It seems that the answer for multi-language support on Windows, is 16-bit
Unicode. If you don't play 16-bit Unicode, you are stuck using the
globally configured code page (Regional and language options setting) for
all programs concurrently running on a particular machine. Of course, you
could tell the user to switch back and forth, or potentially figure out
how to switch it for the user. But I'm not sure what happens if you switch
very dynamically, or even if you can choose appropriate times to switch.
The only other solution I can see, short of porting Win32::GUI to use the
W API (Unicode), is to do all text display via user code, and while it is
possible to make "owner-drawn" controls, it would be very cumbersome to do
that for every type of text in every type of control. And I think you'd
lose a lot of the accessibility, if the menu entries were "owner-drawn"
bitmaps that look like text, instead of being the text itself.
P.S. My interest in this subject is because I also am laboring to support
multiple languages, now including Romanian, in an application.
Fortunately, I only need to support display of Romanian characters inside
edit boxes (RichEdit can do that), and inside images. The images have a
combination of line art, text, and icons... but I do have to support
taking text from the edit boxes (and from UTF-8 files), and placing it
into the images. I have a funny feeling I'll be doing very low-level
Win32::API accessed font and drawing API calls to achieve that, and I
don't look forward to it. I will need to be very aware of the font metrics
and the size of text strings, to do proper placement and layout of the
images as a whole.
--
Glenn -- http://nevcal.com/
===========================
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration
Networking
