I wanted to change the behavior of the Microsoft IME bar using AutoHotkeys, a utility which can be used to create macros, remap keys, or do any of a variety of other related tasks.
This led me to ime_func.ahk, which appears to be an AutoHotkeys script which uses DllCall to access Imm32.dll, the Input Method Manager library. I believe that this script was intended to manipulate the state of the IME language bar.
As near as I can tell, this AutoHotkeys script targets an older implementation of the IMM library. Some of the methods used are now only listed for Windows Mobile platforms.
I began experimenting with ImmGetContext and ImmGetConversionStatus. ImmGetContext always returned a hIMC value of NULL.
On the Developing IME-Aware Multiple-thread Applications MSDN page, the following is stated (bold highlight added):
The IMM includes thread identification checking that determines if a calling thread is the creator of a specified input method context handle (HIMC type) or window handle (HWND type). If the thread is not the creator of the handle, the called IMM function fails and a subsequent call to GetLastError returns ERROR_INVALID_ACCESS.
Additionally:
A thread should not access the input context created by another thread. A thread should not associate an input context with a window created by another thread, and vice versa.
So, it appears that cross-process IME manipulation is forbidden.
I feel your pain – I just hit the same limitation. I’ve been trying to write a program to hook into changes to the language or conversion type, and display a more visual notification on the screen. (I’m always accidently slipping between languages, and don’t realise until I’ve typed a whole bunch of nonsense).
Strangely, there are enum functions in the IMM API that allow you to get the IME context handles for windows in other processes. However, once you have those handles, there’s nothing you can do with them.
I wonder if something can be done with (global) window hooks?