Fixed #583: Make sure IME input is forwarded

[ralphmayr]

Applied the fix proposed in #583 to be able to use IME input with CefSharp

[amaitland]

Splitting each char up and sending individually is very inefficient, whilst I know it's currently required for IME, I'm not inclined to switch that as the default.

Happy to expose SendKeyEvent and let the user implement this solution as required. I think having this code in the WPF Example is benefaction as a reference point. Should be easy enough to override the other key preview code to make the events as handled so the source hook is never fired.

[amaitland]

@ralphmayr If you take a look at amaitland@999f6f3, it's just a rough working idea at the moment as I don't have IME to test. I'm sure we can come up with something that doesn't require users to extend ChromiumWebBrowser, simply hook a few events.

[amaitland]

Any ideas if there's a way to get the IME character from KeyEventArgs? That would simplify things.

[ralphmayr]

Thanks - I fully understand the concerns regarding making that handling the default for all users of ChromiumWebBrowser. I very much like the idea of exposing that via callbacks so that clients may decide how to handle that.
One thing I noticed while looking at your changes is that currently the ChromiumWebBrowser doesn't expose "SendKeyEvent" - right? So I wouldn't be able to implement a handler for PreviewTextInput that transforms the IME input into key events and sends them to the ChromiumWebBrowser object itself at the moment?

[rassilon]

On a slightly unrelated note, could you see if IME works properly with one of the WinForms example apps? As @amaitland said most of us don't know much about IME issues, let alone how to use one if we installed ourselves a VM that we added an IME to.

Thanks,
Bill

[amaitland]

One thing I noticed while looking at your changes is that currently the ChromiumWebBrowser doesn't expose "SendKeyEvent" - right?

You are correct. ad56dbb Should fix make that available 😄 I've also changed the signature to take int for all three params, makes it a little cleaner.

I very much like the idea of exposing that via callbacks so that clients may decide how to handle that.

Maybe we can even had some sort of bool to toggle the behavior? If it's an optional thing then I'm more than happy to see the code included in ChromiumWebBrowser. Ideas/suggestions welcome 👍

[ralphmayr]

@rassilon, I tried it out with the WinForms sample app that is included with the CefSharp source, and it works fine there.
For the sake of completeness, here's how I test that on an English Windows 7 machine:

1. In the Control Panel, under "Region and Language" go to "Change Keyboards"
2. Add the Japanese keyboard layout "Japanese" as well as "MIcrosoft IME"
3. You can leave your current keyboard layout as the "Default input layout"
4. Open a sample app
5. In the language bar (the "EN" icon in the task bar that you should see now), change the input language to Japanese
6. In any text filed in the sample app, press Alt+^
7. You should see in the language bar that the input mode that is displayed besides the JP icon now chnages to Hiragana
8. Start typing - e.g. "nihongo" - that will give you the IME input. Depending on your sample app this will either open the popup IME editor, or do inplace editing. In notepad for example you get in-place editing whereas in the embedded browser control in the CefSharp WPF sample you get the pop up editor:

@amaitland, I guess the nicest thing to do would be to expose SendKeyEvent on the ChromiumWebBrowser, and add the code that actually handles the IME stuff only to the WPF sample app. That way the change doesn't need to be made invasively in CefSharp but still anyone who is interested can see how to apply that to his app, right?
So I changed the pull request to do that instead of the original intention to doing it wihin the ChromiumWebBrowser.

[amaitland]

So I changed the pull request to do that instead of the original intention to doing it wihin the ChromiumWebBrowser.

Excellent, thanks!

[Antonyo]

#901 can also fixed with this change. @ralphmayr did you get inplace editing in a WPF browser? the IME popup appears in the top left side of the screen and it's somewhat annoying.

[mookrs]

@Antonyo @ralphmayr I heared that Microsoft had abandoned Input Method Manager (IMM) from Windows 8, instead of it they use Text Services Framework (TSF). I don't know the "top left" problem because of CEF upsteam or the IME. Just provide some informations what I know. :)

[amaitland]

#901 can also fixed with this change.

@Antonyo Thanks for the update. Glad you found a workaround. I think it's a big of a hack, though if it works then great.

[Antonyo]

Hello, this fails if you use alt codes. The WM.CHAR is send to the source hook even if it´s handled previously in the OnPreviewTextInput event so inputted character is duplicated.

You can recreate it by running the test WPF project, browsing to any input box (google for instance) and pressing an alt code, for instance alt+Num1 to see a duplicate ☺

Is there any chance to make the sourcehook method virtual so we can override or any other solution that prevents the hook to receive the CHAR message without a hacking.

[amaitland]

Is there any chance to make the sourcehook method virtual so we can override

Feel free to submit a PR

[Antonyo]

Thanks @amaitland , I already did.