I am using VC 9 and I want to support Russian language for my application. I even created Russian resource strings. But my system has Russian Language setting. If it is not there every character displays junk (its code page is 1251). I also made DLL from Russian resource file. If I run that DLL in application from installed location, it works fine.
But when I change computer setting to English and run that DLL from appilcation, dialog and message box shows junk character. But shouldn't application read from DLL, not from computer language setting? Here I am facing problem how to make a language independent DLL. Any code or setting for this?
By far the easiest solution is to stick to Unicode.
Windows is Unicode internally. (Almost) Every API function exists in two variants, FooA and FooW. THe FooA variant converts char's to wchar_t's before calling FooW. The exact conversion is defined by the code page.
Now, if you use Unicode, there is no such conversion, and no code page. If the user enters ж (U+0436, it is stored as wchar_t(0x0436) and never converted. If your resource contains ж in Unicode, it too is not converted.
If the strings you want to display cannot be represented in the system code page, the only solution is Unicode.
Related
We have an MFC Windows Application, written originally in VC++ 6 and over the years updated for newer IDE, currently developed in VS2017.
The application is built with MBCS (not unicode). Trying to switch to Unicode causes 3806 compile errors, and that is probably just a tip of an iceberg.
However we want to be able to run the application with different code page, ie. 1250 (Central European).
I tried to build a small test application, and managed to get it to work with special characters (čćšđž). I did this by setting dialog font to Microsoft Sans Serif with code page 1250.
The same approach in our application does not work. Note: dialogs in our application are created dynamically, and font is set using SetFont.
There is a difference how the special characters are treated in these two applications.
In test application, the special characters are displayed in the edit control, and GetWindowsText retrieves the right bytes. However, trying to write some characters from other languages, renders them as "????".
In our application, all special characters are rendered properly, but GetWindowText (or WM_GETTEXT) convert the special characters to the similar ascii counterpart (čćđ -> ccd).
I believe that Edit control in our application displays Unicode text, but GetWindowText converts it to ascii.
Does anyone have any idea what is happening here, and how I might solve it?
Note: I know how to convert project to Unicode. We are choosing not to commit resources to it at the moment, as it would probably take weeks or months to implement. The question is how I might get it to work with MBSC and why is edit control converting Č to C.
I believe it is absolutely possible to port the application to other languages/codepages, you only need to modify the .rc (resource) files, basically having one resource file for each language, which you may rather want to do anyway, as strings in menus and/or string-tables would be in a different language. And this is actually the only change needed, as far as the application part is concerned.
The other part is the system you are running it on. A window can be unicode or non-unicode. You can see this with the Spyxx utility, it tells you whether a window (procedure) is unicode or not (Window properties, General tab). And while unicode windows do work properly, non-unicode ones have to change encoding from/to unicode and mbcs when getting or setting the text. The conversion is based on the system (default) code-page. This can only be set globally (for the whole machine), and not per application or window. And of course, setting the font's codepage is not enough (and imo it's not needed at all, if you are runnign the application on a machine with the "correct" codepage). That is, for non-unicode applications, only one codepage will be working properly, the others won't.
I can see two options:
If you only need to update a small number of controls, it may be possible to change only these controls to unicode, and use the "wide" versions of the get/set window-test functions or messages - you will have to convert the text between unicode and your desired codepage. It requires writing some code, but has the advantage of the conversion being independent from the system default codepage, eg you can have the codepage in some configuration file, in the registry, or as a command-line option (in the application's shortcut). Some control types can be changed to unicode, some others not, so pls check the documentation. Used this technique successfully for a mbcs application displaying/editing translated strings in many different languages, but I only had one control, a List-View, which btw offers the LVM_SETUNICODEFORMAT message, thus allowing for unicode texts, even in a mbcs application.
The easiest method is simply run the application as is, but it will only be working on machines with the proper default codepage, as most non-unicode applications do.
The system default codepage can be changed by setting the "Language for non-Unicode programs" option, available in the regional settings, Administrative tab, and requires a reboot. Changing the Windows UI language will change this option as well, but by setting this option you don't need to change the UI language, eg you can have English UI and East-European codepage.
See a very similar post here.
Late to the party:
In our application, all special characters are rendered properly, but GetWindowText (or WM_GETTEXT) convert the special characters to the similar ascii counterpart (čćđ -> ccd).
That sounds like the ES_OEMCONVERT flag has been set for the control:
Converts text entered in the edit control. The text is converted from the Windows character set to the OEM character set and then back to the Windows character set. This ensures proper character conversion when the application calls the CharToOem function to convert a Windows string in the edit control to OEM characters. This style is most useful for edit controls that contain file names that will be used on file systems that do not support Unicode.
To change this style after the control has been created, use SetWindowLong.
I have to maintain a small C++ / VS2015 project in my department which only checks the installed .NET Framework of a machine and prompts the user if the current version is not installed. This small application is localized by a file called Language.rc which contains some STRINGTABLES with the corresponding texts.
All this works fine if the program is compiled on my machine, but if the same code is compiled on our build machines then the special characters like for example the German ÄÖÜ are missing.
Unfortunately I'm not a c++ person and I have no clue what is wrong. I already searched the web but cannot find a hint on what might be the problem.
Does anybody have an idea what could be different on the build machines compared to my machine that causes the different characters?
UPDATE:
So after my TFS expert has analysed the problem on the build machines we were able to identify the culprit:
As I said before the application that was causing the problem is only a small tool. Our automatic build contains a lot more solutions and projects. One part of the automatic build is a script that sets the version numbers of all kinds of files to the same value. This is apparently also done for so called RC files. As far as I understand there are different kinds of RC files in C++ (and also in Delpi) which actually hold version numbers. The RC file in my case only has texts and translations but is opened and also saved even though it does not have a version number.
Unfortunately this operation also explicitly sets the encoding of the file to some old IBMxyz encoding (maybe for the Delphi RC files?). This is the actual operations where the special characters get lost... So the solution to my problem is not within the original encoding of the file but somewhere in the build process.
As a temporary fix we changed the .rc file to an .rc2 file - this way the project still compiles but the build does no longer modify it.
I've had enough fun for today...
Windows has two ways of handling text. These are known as "Unicode" (really UTF-16) and "ANSI" (which isn't related to the ANSI standards organization, and describes any 8 bit superset of ASCII).
Your problem is clearly a case of "ANSI" disease. ASCII does not contain "Ä", some supersets of ASCII do, but not all supersets do. Different machines using different supersets will cause different results.
The "simple" fix is to prefix an L to the string in the .rc file: L"zum Beispiel", and then save this .rc file as Unicode (UTF-16). While newer versions of Windows contain more UTF-16 characters, this never affects existing characters, and Ä has been part of every Unicode version. (Even € works everywhere - I think that was added in Windows 2000)
I am finishing application in Visual C++/Windows API and I am using MySql C Connector.
Whole application code uses ANSI, MySql C Connector is in ANSI too.
This program will be used on Polish and German computers with Windows XP/Vista/7 or 8.
I want to correcly display german umlauts and polish accent characters on:
DialogBox controls (strings are loaded from language files)
Generated XHTML documents
Strings retrieved from MySql database displayed on controls and in XHTML documents
I have heard about MultiByteToWideChar and Unicode functions (MessageBoxW etc.), but application code is nearly finished, converting is a lot of work...
How to make character encoding correctly with the least work and time?
Maybe changing system code page for non-Unicode program?
First, of course: what code set is MySQL returning? Or perhaps:
what code set was used when writing the data into the data base?
Other than that, I don't think you'll be able to avoid using
either wide characters or multibyte characters: for single byte
characters, German would use ISO 8859-1 (code page 1252) or
ISO 8859-15, Polish ISO 8859-2 (code page 1250). But what are
you doing with the characters in your own code? You may be able
to get away with UTF-8 (code page 65001), without many changes.
The real question is where the characters originally come from
(although it might not be too difficult to translate them into
UTF-8 immediately at the source); I don't think that Windows
respects the code page for input.
Although it doesn't help you much to know it, you're dealing
with an almost impossible problem, since so much depends on
things outside your program: things like the encoding of the
display font, or the keyboard driver, for example. In fact,
it's not rare for programs to display one thing on the screen,
and something different when outputting to the printer, or to
display one thing on the screen, but something different if the
data is written to a file, and read with another program. The
situation is improving—modern Unix and the Internet are
gradually (very gradually) standardizing on UTF-8, everywhere
and for everything, and Windows normally uses UTF-16 for
everything that is pure Windows (but needs to support UTF-8 for
the Internet). But even using the platform standard won't help
if the human client has installed (and is using) fonts which
don't have the characters you need.
I am a .NET guy who is having to do some work on an MFC app. The app is a VS2008 MFC executable which I have converted to VS2010. The original developers did localisation by specifying the name of a .txt file with key value pairs in it on the applications command line. Installed shortcuts to the executable specify a different .txt file depending on which country the app is being installed in. This of course does not work if you just run the .exe directly. This seems like a weird way to do things to me.
I want to do this the propper MFC way, but I am having difficulty finding definitive answers on Google. My understanding is that the String Table in the .rc file should be used for this localisation? Is this the current best practice for MFC?
With respect to the String Table I have read that the practice is to create multiple string tables each for a different language. How do MFC applications choose which language to use? Is it based on the machines current language settings or can I control this (it may be that we want the language to be specified by the Wix .msi installer we are also building)?
I have also read that embedding all resource inside an MFC application has fallen out of favor and that now you should compile seperate resource .dlls? Is this is true ill investigate how to do it...
Finally, do I have to do something special to get MFC to support Unicode or is MFC Unicode by default?
Thanks
The idea is that all localizable items should be stored in resources. Standard UI objects such as menus and dialogs are automatically stored in there (resources) for you but items such as string literals (eg: error messages, messagebox prompts,...) should be pulled from source code to the string table. This short codeproject article of mine demonstrates how to easily pull strings from the string table in your code.
Note: You should have only one string table in your resource script (.rc).
From there on, you can translate your resources and create resource DLLs (aka satellite DLLs). The idea is that you keep a different copy of the .rc file(s) for each language. Each translation is compiled into a codeless DLL that acts as a container for the resources.
This other codeproject article of mine lets you easily load resource DLLs according to system settings or user preferences: The code looks among your resource DLLs which available language best matches user settings (based on user's UI language and regional settings). The code also lets you easily build a menu with all available languages. That way, your user can override the default choice.
DISCLAIMER: My ad follows. Feel free to skip :-)
Regarding the translation of resources, the management of translations and the creation of resource DLLs, you may want to check out appTranslator.
END OF AD :-)
Regarding Unicode, MFC ships with ANSI and Unicode versions of the code. It's up to you to choose if you want to build an ANSI or a Unicode app: Just make your pick in the first page of project settings. Of course, if you are startgin from scratch, you should definitely go Unicode. But if legacy reasons force you to stay ANSI/MBCS, don't worry to much: It won't prevent you from localizing your app.
Years ago when I had to work with multiple languages in MFC, we used separate resource DLLs. All you need do is make one call to switch which handle the resource functions would use and all was automatic from that point forward.
You need to do more than just change the strings. Dialogs in particular will have strings inside of them, and you may need to change the layout if those strings become too long after translation.
Our application calls ShGetFolderPath when it runs, to get the My Documents folder. This normally works great. However, for three users - Дмитрий, Jörg and Jörgen (see if you can spot the pattern!) - the call returns some very strange results. For example, for Дмитрий, the call returns:
c:\Users\???????\Documents
I assume there's some sort of character encoding shenanigan going on here, possibly related to Unicode, but I don't have any experience with that sort of thing. How can I get a useful path to the folder (and other related folders) out of windows, without grovelling through registry keys for the information?
In an email to me, Дмитрий ("Dmitry"), told me his "my documents" folder was actually located here:
C:\Users\43D6~1\Documents
So I know there's a way to get a "normal" version of the path out of Windows, I just don't know what it is.
Background: Our application is not unicode-aware, and uses standard "char *" strings. How can we get the "normal" path? I'm not opposed to calling the "unicode" version of the function, then converting it to "normal" text, if that's possible. Converting the application entirely to use unicode is not an option here (we don't have the time).
Thanks.
Go ahead and get the file path in Unicode. Then call GetShortPathNameW to convert to short pathname components. The output shouldn't contain any characters outside of the ASCII range even though it's a Unicode function. You can then truncate each Unicode character back to 8 bits to create a char string.
I'm not opposed to calling the "unicode" version of the function, then converting it to "normal" text, if that's possible.
If you change your call to SHGetFolderPath to SHGetFolderPathW, it will provide you with a string of type LPWSTR, which is a Unicode string. From there, you can use that string with the various Unicode functions that end with W to access the folder or files you need.