Localisation not working in static control [duplicate] - c++

This question already has answers here:
Get text width in MFC
(4 answers)
Closed 8 years ago.
I am developing one Window based application, As it is window based desktop application I need to support multiple languages from Chinese to french and from Hindi(Indian) to Portuguese(Brazil) now thinks work great still there same size of text for display.But for following example,
If my one static control contain following text
Select Output Range |_Text Box__|
As i am developing it in English so size of static is considered according to English text size. Thinks work great.
Now same text i converted into Chinese view of above static control is like follow,
选择输出范围 |_Text Box__|
I am happy as size of Chinese is less than size of English but when i convert same text from English to french following is size of static control,
Sélectionnez Plage de sortie|_Text Box__|
My bad size of text is increased by some worlds as we have big text on less size text, View of text will clipped like following way,
Select Output Range |_Text Box__|
Sélectionnez Plage |_Text Box__|
In french size of text is increase ,So how to handled mismatch of text size pro-grammatically?

There are different ways to handle this problem. The answer depends on the way you handle the localisation in your code.
Note that some locals need the display to be inverted from left to right -> right to left (arabic...)
In this case you will have to handle cases where:
Select Output Range |_Text Box__|
must become:
|_Text Box__| <translated text into arabic or hebrew>
So you must be aware that translating a dialogbox is not just translating the labels. You have started noticing that because label lengthes are not the same.
If you choose to have a very simple localisation mecanism, like having a text file (containing the list of all labels) for each language, then you cannot do much more than trying to size your labels with a one-size-fits-all-languages. Dialogboxes won't look very nice in some languages. And you won't be able to use right-to-left languages. This is the quick and dirty way.
If you want to go further, the most common way is to have a resource file for each language. When your program is almost done, you have to duplicate the resource file. You have a copy for each language. You localize the whole dialogboxes, menus, etc. When you localize a dialogbox in French, you can make the label fields larger. And smaller for chinese. You can also change the dialogbox layout for arabic if you want.
Of course you have to build a version of your software for each language.
Your post has the MFC tag, so I suppose you might be interested in the MFC extension DLLs. This is the standard way for an MFC app to handle localisation. You create a DLL that only contains a resource file. If you support 10 languages, you duplicate and translate 10 resource files, and you create 10 extension DLLs. The MFC automatically load the right DLL depending on the current Windows locale. See for exemple a sample on CodeProject
I would not advise you to write some code that would automatically move and resize the controls when the dialogbox is created, because this is not as easy as it seems. Unless your app is quite simple.

Related

W10/Wins32 C++ How to determine what characters are available to write to an HDC

My goto font for code text editing, in my own editor, has, for years, been Consolas.
I thought its coverage was good but then I discovered that W10 was adding an automatic fallback so even my Ancient Egyptian hieroglyphics font (U+13000 et al) would appear.
Now my editor (internally UTF-8 multi-byte but switching to WCHAR for display including packing two part 21 bit Unicode which the SDK handles nicely) has offered a pop-up box that provided a quick and easy access to characters not on my keyboard and that used GetFontUnicodeRanges() to determine the coverage.
This is obviously now woefully inadequate. I've searched but not found a way to determine what character codes will result in a character on the display and yet Windows is doing it effortlessly at runtime. I can ask about any individual font I want to load but not what will happen.
I must be missing something. I really don't want to resort to writing whole blocks of text to an HDC to a bitmap and then pattern matching on that for the old rectangle or the ? in a box we all know so well.
Has somebody already done this?
Is there a magic trick I am missing?
I am retired now so I have time to delve but I've run out of ideas.

How to ensure rendering of digits as arabic numerals on Windows 10?

My application allows users to customize UI by selecting a user preferred language. It usually works great, except that on Windows 10, say, if a user locale is picked as, say, Cambodian in Windows Control Panel:
But then if the user in my app's UI picks US English, I can't seem to find a way to render it with "US English numbers." On Windows 8.1 it used to end up looking as such, no matter what locale is picked:
As my assumption was that one doesn't need to translate numbers. But on Windows 10, that same control ends up looking as such:
Note that its text is set up using just this call:
::SetWindowText(m_hWnd, L"1000");
So I am curious, is there any way to keep numbers rendered as the arabic numerals:
This issue goes much deeper than basic controls, it happens inside GDI and also affects DrawText and TextOut. The only documented way around it is to call ExtTextOut with the ETO_NUMERICSLATIN flag (or use Uniscribe to render text).
This behavior is completely by design
these flags only modify U+0030 -- U+0039, as needed
Becsause the truth is that GDI doesn't give a crap about formatting or really anything related to locales, with one signle exception: Digit Substitution
Any time you go to render text it will grab those digit substitution settings in the user locale (including the user override information) and use the info to decide how to display numbers.
Another thing that seems to work is to force a custom font with the GREEK_CHARSET charset. That charset triggers a font association magic feature. (EE_CHARSET also seems to work for English text). You would probably have to try to pick the best charset for each of your languages if you are going to do this but you cannot use ANSI_CHARSET nor DEFAULT_CHARSET.
If don't know why this only happens in Windows 10 but it really seems like a bug in certain places. In Explorer for example it will display "7-Zip" as "៧-Zip" etc.

Multiple fonts in C++ dialog

Is there a simple way in C++ (and if yes, how to do it, preferably within Visual Studio VS2012) to set different font properties (size, type, bold, etc) for different elements of one dialog window (button, static text, title, etc)?
The font properties of a dialog window can be modified in its 'properties' dialog in VS2012, but they are then applied to all the window elements.
My need is to emphasize some information wrt other in the same window, e.g. to make it visually easier to differentiate labels from variable values, and static from modifiable variables.
Thanks for any help.
In a recent and well written article, John Morrison Leon presents his solution which precisely addresses this issue and more.
On top of enabling the wished for possibilities with formatting, it offers a whole new way to easily create and use dialog windows, purely C++ (Win32 without MFC or ATL/WPL, independent of the IDE, mapping at compile instead of run time).
The piece is a rather detailed tutorial, licensed under The Code Project Open License (CPOL). It contains all C++ source code (37.2kB zip) and examples (80+kB). It has won Best C++ Article of May 2015 (First Prize).
------------- some excerpts quoted from this (long) article -----------------------
An alternative approach in which dialogs are entirely specified as C++ code that requires neither IDE support to be written nor IDE generated resources to be executed. Powered by the C++ type system.
The fundamental difference with the approach presented here is that your code does all the work of creating the dialog rather than have Windows create a dialog from a dialog template resource that you then attach code to. There is no need for dialog or control ID's because there is no run-time mapping of code to a dialog template. Instead there is compile time mapping of each control to a C++ variable. Furthermore each of those variables has its own unique data type. Such rich typing is perhaps radical but it brings many benefits and is key to the design. It allows the C++language to resolve many issues at compile time through type resolution and this reduces and simplifies the code that you have to write. In practice this means that for every variable representing a control, say btnCancel, a unique data type will be generated with the same name prefixed by an underscore _btnCancel.As you will see, there are times when you will need to refer to a control by its data type _btnCancel rather than its variable name btnCancel.
The unfamiliarity of coding a layout instead of dragging and dropping it is dealt with in the next section and after that, most things are simpler, cleaner and more concise than you are probabaly used to.
There are some other innovations including:
•all control variables carry a dynamic text dynamic text buffer as_text through which the controls window text may be read and written, and which persists when the dialog is closed.
•support for non-windows controls that are simply painted onto the dialog and respond to mouse events. (examples are provided for some cases where this makes more sense).
•support for imposing aesthetic metrics (button sizes, spacing, colours, control styles etc.) at an application level on all dialogs hosted.
•replacement of the notion of 'Anchors' with Expand_X and Expand_Y styles for controls that can benefit from being enlarged if the dialog window is enlarged.
•some modest but effective streamlining of Win 32 programming with controls.

Application using two (human) languages

I have a fully working code, written for Windows, built with Visual Studio.
What I want to do, is to add another language to that software. My idea is to have two flags (one English and one German) in the window corner, and to have the language change when user clicks on one of the flags.
What is the common, and best way to do this kind of thing?
So far, my idea is to create two files, and to store all the strings that software will use in those files. One file would hold all strings in English, and the other file will hold all strings in German.
Then, I believe that, when a click on a flag icon is detected, software would load all the strings in a list, or vector, or something similar, and then, I would just printout whichever string i need with vector.at(i).
Also, how would I save the currently used language on application exit, so the next time the app is started, that language is used?
The most commonly used way is more or less same as your idea. Also, to store currently used language on exit, you can create a configuration file writing the lang at application exit and read it on app start.

C++ Win32: fast word processing-style text rendering under Windows 7

At user request, my (for now C#) application reads big chunks of rich text (for now, in .NET FlowDocument XAML format) from a SQL Server database, and displays it.
I use a C# RichTextBox for that, it works but the whole thing is much too slow (the whole application is not very responsive). I want to remake everything in native C++.
What is the best way to get fast rich text rendering in Windows 7?
I would welcome suggestions
1) on the text API to use (Direct2D/DirectWrite or GDI or something else? use glyphs or higher level functions?),
2) also on how to store the rich text in memory to accomodate scrolling up and down the flow of text, insertion in the middle of the text etc.
Thanks.