I think I found the source of our misunderstanding.
To me, this is the terminology (Windows 2000):
User locale (aka "User default locale"): the locale as appearing in the "Regional options" as "Your locale (location)".
System locale: the locale as appearing in the "Regional options" as "Set default".
Under XP, the terminology is a little better:
User locale: "This option affects how some programs format numbers, currencies, dates and time" ("Regional options" tab in the control panel applet).
System locale: "Language for non-Unicode programs" ("Advanced" tab in the above mentioned applet).
Changing the system locale does require a reboot. If it did not require a reboot, you did not change the correct locale. If you re-run the below test, I believe you will find that there are, indeed, two distinct settings.
Shachar
Dmitry Timoshkov wrote:
"Shachar Shemesh" <[EMAIL PROTECTED]> wrote:
Ok. Then please do the following experiment for me, will ya?
1. Hover the mouse over the clock. The date is displayed. Watch the date display language.
In the language of the system locale, russian for me.
Now go to "Regional options", and change the setting to "English (U.S.)". Hover over the clock again - see how the date display setting changed? Obviously, the user locale affects the date format.
That's the system locale again, and yes, when the system locale changes, date format changes as well.
2. With the user locale still in English, open Word and save a document with a file name in Russian. Look at it in Explorer, and make sure it is, indeed, in Russian. Use Word's "open..." dialog to open the file. Obviously, Word can still interpret the file's name as Russian, despite having it's user locale set to English.
3. Switch your system locale to English. This will require a reboot.
It *does not* require a reboot, that's exactly the same thing as #1 above and demonstrates exactly the same behaviour.
You are trying to persuade yourself by taking into account only the look of the Windows. Please write a test app how I did and see what data GetSystemDefaultLCID and GetUserDefaultLCID return.
Open the folder containing the file in Explorer (a unicode application) - the name is still Russian. Now try to open the file in Word (a non-unicode application).
Word is a *unicode* application when it's running under NT. It uses a sophisticated system of API pointers for that task in order to run under Win9x and NT.
It matters not if you double click the file or go through the "File/Open" dialog. The file will not open. With the system locale set to English, word has no way to tell CreateFileA to open a file who's name is outside the current codepage.
This, at least, should convince you that system locale and user locale are distinct things.
I see that you do not understand, that there is no user locale at all under Windows, and therefore there is no way to change user locale. There are just adjustable per user locale data in the registry. Please realize that, otherwise it's a useless discussion, pointing again and again to the same facts.
The question is not whether confusion will arise from using different system and user locale. The question is whether it's supported, and whether we should support it as well.Any attempt to have more than one active locale simultaneously will lead to confusion and nothing else, be it unix environment or win32.
It can't be supported in any sane manner since characters can't be mapped between incompatible charsets like hebrew and russian, and therefore characters from those charsets can't be displayed simultaneously by a not unicode application. That's exactly what you are trying to accomplish. Just realize that.
Please do report the results of the above test. If they are anything other than what I have said, I'll be glad to amend my understanding of Windows.
Your understanding of Windows is based on conclusions you made by observing visual effects, not API behaviour.
-- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
