The app I'm developing requires that it be deployed in China, which means that it needs to have Pinyin and Chinese character handling. I'm told that the way that our customers handle character entry is like so:
Enter in the pinyin character, like 'zhang'
As they enter the characters, a list of possible Chinese (Mandarin?) characters are presented to the user, like:
The user will then select '1' to enter the family name that is roughly translated to 'zhang'
How can I hook such programs (I believe one is called 'mspy.exe', from Microsoft, which I'm lead to believe comes with Microsoft versions of XP) into a WPF text box? Right now, the user can enter text either by using their keyboard or by using an on-screen keyboard, so I will probably need to capture the event of a keypress from either source and feed it to some OS event or to MSPY.exe or some similar program.
Or is there some other way to enter pinyin and have it converted to Mandarin? Is there a program other than MSPY I should look at?
EDIT: For those of you who think that this should 'just work', it does not. Chinese character entry will work just fine if entering text into notepad or the start->run menu or whatever, but it will not work in WPF. That's the key to this question: how do I enable WPF entry? There's the Google Pinyin and Sogou pinyin, but the websites are in Mandarin or Chinese or something similar and I don't read the language.
In all likelihood the system will handle this automagically if a Chinese input method is selected by the user. Trying to implement your own system for dealing with Chinese text is probably a bad idea.
Be sure to test it on a Chinese version of XP before deploying, of course, but with any amount of decent design in WPF, and XP as a whole, at all; it should Just Work.
Not really an answer to your question, but as far as I know, this is handled by the operating system, and I'm not sure that application really have that much control over it.
Here's a guide on how you enable pin yin Chinese character entry in Windows XP:
http://www.biblioscape.com/tips/tip_020318.htm
My application works with chinese input, and it is using WPF, i don't get what you want to ask.
You can input chinese text in a WPF textbox using sogou pinyin, or microsoft pinyin. Tested in xp and win7
It is just because your ime is setted to input in english.
Press shift once briefly if using sogou pinyin and you will see the hanzi of "yi" become "zhong"
At that point you will be able to type in chinese ;-)
Also, there are IME property on textboxes, select to have it On, otherwise the IME will be in "english mode"
Related
Question
On Windows, if a program does not use one of the native APIs to produce a GUI, then Windows IME shows a tiny Textbox in the upper left corner to input IME strings, as is the case with Japanese.
Can this textbox be moved programmatically via the Windows API? I just want it moved roughly where the text input happens, so it's not so jarring having to look in the upper left corner all the time. Can someone point me in the right direction, what to read where to search?
Details
I have an OpenGL Program with a simple Immediate-Mode GUI Toolkit on top. As such this program does not interface with the OS's GUI capabilities in any meaningful way to provide OS native behaviour or accessibility functions. For my use-case, similar to many video games, this is fine. If I have textboxes inside the program however, inputting text via Windows or Google IME is an awful experience and I would like to improve it. I am not looking to integrate with Windows any more that this, just moving the IME Textbox roughly to the correct position of the "in program" textbox. It is compiled with MinGW64 and I already used Win32 API functions like changing the program's window and taskbar icon. Is this a possibility via the Win32 api?
The following code works in moving the IME position from default to current cursor position:
if (msg.message == WM_IME_STARTCOMPOSITION) { // msg is windows message
HIMC imc = ImmGetContext(msg.hwnd);
COMPOSITIONFORM cf;
cf.dwStyle = CFS_FORCE_POSITION;
POINT ptPos;
bool ret = GetCursorPos(&ptPos);
if (ret)
{
cf.ptCurrentPos.x = ptPos.x;
cf.ptCurrentPos.y = ptPos.y;
}
ImmSetCompositionWindow(imc, &cf);
ImmReleaseContext(msg.hwnd, imc);
}
WM_IME_STARTCOMPOSITION is a message type which windows sends to application when it starts IME. In your application when you peek or process windows messages try to catch for WM_IME_STARTCOMPOSITION and then force set the IME composition window position.
I'm trying to make a simple autocompletion tool for my program, and i would it look like as this picture : https://github-camo.global.ssl.fastly.net/ac6492f955c9d8027b6f691e1e3df6052fa16599/687474703a2f2f6e6f736d696c65666163652e72752f696d616765732f63636f6465322e706e67
There are termcaps who can help me to make this ? As a little "te" "ti" capabilities ?
Thank you.
Generally, you cannot get the screen contents, because some people view the notion of an escape sequence which can return the screen contents as a security problem.
The xterm ti/te termcap capabilities do not return the information on the screen. Instead, they tell xterm to switch between the normal and alternate screen buffers. But those cover the entire screen -- not a portion of it as your example suggests. Also, these sequences are sent by any conventional application at the beginning and end of "full-screen" mode -- so your application is likely already using the alternate screen.
Instead, your application has to keep track of what it puts on the screen, so that it can repaint after the popup window goes away. That is something that ncurses, for example, is designed to do.
Originally the question was "How do WinForms capture and process user input", but since I want to use that for my XNA game, well, you can see the title.
I'd like to never miss a key stroke in my game, but XNA's default way of updating user input is dependent on framerate, and Nuclex.Input doesn't care which Shift or Ctrl I press, doesn't detect some keys (including F10, left Alt, PrintScreen and Pause), so they won't work for me.
Is it possible to implement the same way of capturing user input in an XNA game, as the one used in WinForms applications, and how?
I am trying to implement a text box where a user can type, use arrow keys, backspace, delete, etc. I would like to be able to know what is in this text box without the user needing to submit anything. I suppose I could catch keypress events, find a way to display a cursor, and basically build a min-text-editor by hand--but maybe that would be reinventing the wheel?
What I am after is rather scrabble-like. You have several letters in the top part of a window and a text box in the bottom. Each time you type a letter it disappears from the top pane so that you know when you've used them all up. I want to be able to edit that text with the arrow keys, 'cause rather than the 7 letters scrabble would give me I hope to be doing this with paragraphs.
I have the window displaying, and the source file processed and displayed as a list of allowable letters... I just want to update the list of allowable letters while the user types in their sentence. Can Xlib do this? Is there something else that might be more suitable? Thanks!
Can Xlib do this?Why yes, Xlib can do a lot of things. What you describe seems simple enough by using X's event processing and drawing functions.
Xlib is pretty crufty, though, and IMO you should only use it if you need closeness to the X protocol. (Even then there are newer replacements like XCB. But I digress.)
You might find it easier to work with a modern toolkit, like GTK+ or Qt.
For example, this might be expressed as a GtkEntry with a "key-press-event" handler.
In WPF text block, I want to display special characters like diamond (♦) etc. It is displaying fine in some systems and in some systems, it is displaying a plain box instead of the symbol.
Can somebody help me to resolve this issue.
Thanks in Advance.
-Elangovan.
When you want "special characters" you should probably use images instead of depending on fonts. For one thing, you have no guarantee that the user will have the font you use.