We need our application to be able to accept languages such as Korean/Japanese etc. as input.
However, if I have my Keyboard language set to Korean then in the bottom right of the task bar I get this:
and if I try to input anything, It's just regular english characters.
In any other windows application (including stack overflow) I can input these characters (ex ㅔㄹㅎ), and this is what the taskbar looks like:
I'm using Qt and C++, is there any way I can get the same behaviour as any other application?
We are using custom text edits rendered with OpenGL/DirectX. On the Gl/Dx widget I needed to add setAttribute(Qt::WA_InputMethodEnabled); in order to enable the IME.
Try changing the default locale of your Qt application to the language you are targeting.
QLocate::setDefault(QLocale("ko_KR"));
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.
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.
Which setting in an MFC app controls the title shown in the windows 7/8 jump-list, just below the actual list of jumps, above the pin application option?
This is mainly so that a localised string can be used for non-english systems.
My first thought on this problem was that it could be set in the version resource file, although adding a new localised section (sweden in this case) and setting the description/file name does not seem to affect the text i'm interested in.
Finally figured this one out, the name used here and in several other places is set in a registry key for the application at
[HKEY_CLASSES_ROOT\Applications\AppName.exe]
"FriendlyAppName"="This text is shown"
Some documentation can be seen here: https://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx#applications
I'm trying to paste emoji's in the QT QTextEdit box but it's not getting recognized and it's showing as ??? or [][]
I'm not talking about smiley, I'm talking about emoji.
How can I go about making sure that QT's QTextEdit accepts emoji and displays them correctly?
Thank you.
Got it based on the helpful answer below:
SOLUTION:
QFontDatabase fontDB;
fontDB.addApplicationFont(":/Resources/fonts/seguisym.ttf");
QApplication::setFont(QFont(QStringLiteral("Segoe UI Symbol")));
A considerable number of emoji characters are in the Unicode Standard.
If you're, for example, developing with Qt 5.3 in Mac OS X 10.9, pasting emoji characters in text edits should work as it does when pasting any other character.
The reason why your application is showing ?'s and/or []'s is because the current font (perhaps the default system font) doesn't provide representations for emoji "characters".
You can find a proper font out there in the web. Check this for reference.
Then you can add the font to your Qt application
QFontDatabase fontDB;
fontDB.addApplicationFont(":/A Font Supporting Emoji.ttf");
and set it as the font for your application or only your QTextEdit if you prefer
setFont(QFont(QStringLiteral("A Font Supporting Emoji")));
With this your app should be able to display emoji.
The Qt documentation of QTextEdit::paste() says: To change the behavior of this function, i.e. to modify what QTextEdit can paste and how it is being pasted, reimplement the virtual canInsertFromMimeData() and insertFromMimeData() functions.
There you should be able to convert the pasted data e.g. to an HTML img element pointing to a file that is embedded into the application by ressource compiler (or to image file on disk).
Title says pretty much everything. Once upon a time when I was under 13, my older bro did in BorlandPascal a thing which amazed me. He defined kind of table [8][8] with values of 1 and 0, meaning respectively foreground and background. Having several of such tables he could somehow redefine default ASCII characters to look like in these tables. I have no idea how it was done, but it worked.
My question is: can I do similar thing in ncurses, and if I can then how to do it?
The short answer is no. What ncurses does is generating ANSI escape codes which are interpreted by the terminal. There are no codes for altering the font. (Althou there have been extensions propesed no commonly used terminal supports them, neither does ncurses.) And there is no generic way of communicating with the terminal through some kind of side channel for changing the font. But there might ways in some specific situations.
If you have direct access to a Linux console for example you could could do all sorts of things, much like in Borland Pascal. But it will likely be more messy and less impressive.
As the selected answer explains, this is not possible for NCurses to render custom glyphs. ncurses only manipulates the terminal screen state via escape codes (Clearing and rewriting lines to achieve interactivity).
However it should be noted that's very possible to use custom glyphs in the terminal via custom fonts.
This is what Powerline does (a popular terminal UI status line for vim, tmux and friends): https://github.com/powerline/fonts
By patching the fonts, you can inject your glyphs into the existing font being used by the terminal, which then you can access and render via ncurses as any other character.
Of course this is not ideal solution, but with some auto patching of the fonts, and careful testing, it makes it possible to build an app that uses custom glyphs—when your really in a pinch for more expressive UI tools than ncurses can offer.
Further reading: https://apw-bash-settings.readthedocs.io/en/latest/fontpatching.html