Delphi 7 - Why does Windows 7 change character encoding at runtime?

Question

I have a Delphi 7 form:

and my code:

when I run this form on Windows 7, I see:

At design time, the form had Polish letters in the first label, but they did not have them at run time. This looks fine on Vista or Windows XP. When I set the title of the second label in the code, everything works fine and the characters are correctly encoded.

The first 5 codes of the top mark in Windows 7: 65 97 69 101 83

First 5 Top Label Codes in Windows Vista / XP: 165 185 202 234 140

The first 5 codes of the lower label on each system: 165 185 202 234 140

Windows 7 changes encoding, why? My system settings seem to be in order. The control panel has the correct language for applications that do not support Unicode.

EDIT

This problem is associated not only with labels on forms, but also with FastReport (where switching to EASTERN_CHARSET solves the problem) or with access to Microsoft Excel through the COM interface.

Answer 1

The answers to this question solve my problem:

Does GetThreadLocale return a different value than GetUserDefaultLCID?

One solution:

The strange thing we found is switching to other regional settings using the control panel, and then switching to NZ fixes the problem. I would be curious to know if this workaround allows you to simply verify that we are seeing the same phenomenon.

and second:

initialization SetThreadLocale(LOCALE_USER_DEFAULT); GetFormatSettings; 

Both solutions work fine and the problem with the application disappears.

Answer 2

I reproduced the behavior in Delphi 2010 in win XP.

 procedure Button1Click(Sender : TObject); begin ShowMessage(AnsiString(Label1.Caption)); end; 

In this situation, the conversion of Label1.Caption to AnsiString is done through WideCharToMultiByte (Windows API).

The API has the following note:

ANSI code pages may be different on different computers or may be changed for one computer, data corruption. For most consistent results, applications should use Unicode, such as UTF-8 or UTF-16, instead of special page code, if outdated standards or these formats prevent the use of Unicode. If using Unicode is not possible, applications should mark the data stream with the corresponding encoding name when the protocols allow it. HTML and XML files allow tags to be tagged, but no text files.

So, I think that the difference in behavior comes from the fact that the version of Windows 7 you have has a different active CodePage than on your Vista / XP stations.

I still need to find how to get the active code page in the system ... My best guess is that it is defined in the regional settings of the control panel. But I still need to check this ...

Answer 3

You are faced with what I consider to be an “error” in the TWriter.WriteString and TWriter.ReadString methods. These two methods are internally used by Delphi to move your TLabel.Caption from a real live object at design time to a DFM file, and then back to a live object at runtime.

If you look at the code for these two routines, you will notice (in shock, I suppose) that the actual material that enters the stream is converted to Unicode using the default code page for the operating system! This thin and dandy, as long as the code page used on the development machine, exactly matches the code page used on the test machine, and they probably don't match, and, most likely, why you get the error. Please note that the EASTEUROPEAN_CHARSET parameter that you set for Caption on the form is absolutely irrelevant, because the TWriter.WriteString method does not know about it!

I have a bug report on this issue in QC, it has existed for many years ... They probably consider it "by design", but I do not think it is a very good design.

The solution I would recommend is a quick transition to Delphi 2010. I am a Delphi developer in Romania and I had many, many problems with such things, but now it's all in the past because Delphi 2010 is UNICODE, so I have more No need to worry about code page conversions.

If you cannot switch to Delphi 2010, you may need to “crack” the Classes.pas file and modify the TReader.ReadString procedure to always perform the conversion using the code page, and not by default.

Answer 4

Check the Font.Charset property of the label. Although I do not know how it changed (was it created for some kind of master?) - it may have a different language from the system one.