.Net, Windows 8, etc.

Now that I have gotten the basic stuff up and running, it is time to consider the more tricky stuff.

Installing under Western Languages

The Text Services Framework in Windows is a complex beast... well at least that's how I see it now. For now, for some extremely unclear reasons, it is (almost) impossible to get the IME working under the English US locale. I have gotten it working at some points during development, but as yet it is a hit-and-miss business. This is why the IME currently installs itself under Chinese (Simplified).

Nevertheless, that is not an acceptable solution. More intelligent programs like Microsoft/Libre- Office, even Microsoft Paint, recognize that an Asian language is being used to input text, and automatically changes the font, spellcheck, etc. This is good if we were really interested in inputting CJK text, but we aren't. We are more interested in inputting Greek characters, occasional Latin characters with diacritics and so on, and the sudden change of font will only be extremely annoying.

Hence, I still need to look for a solution to installing the IME as an input method for Western langugaes.

Forms, self-registration, .Net, Visual Studio

The Ctrl+Shift+U combination to activate Unicode input imitates the same functionality in GTK+. As far as I can tell, Ctrl+Shift+U is a keyboard shortcut that is rarely used in applications, or is it not? When I was testing the software under Internet Explorer, I realized that Internet Explorer actually used this keyboard shortcut to display rendering statistics!

Which raised a problem -- so depending on the software you use, you may or may not require a different keyboard shortcut. Alright then, I will provide some means of letting users change activation shortcut.

Then I hit a snag. Visual Studio 2010 does not support C++/CLI forms, only Common Language Runtime (CLR) forms. If I used the latter, it means that I will have to (1) do C++/CLR interop between the form and the control, or (2) convert my entire project into a .Net project, with intermediate code, JiT compilation and all.

(1) is a pain. Hours of research work turned up no good solution (that integrates into the Visual Studio build process), and I suspect Microsoft simply wants developers to focus their efforts on .Net development.

But (2) is not feasible! (2) prevents the IME DLLs from being registered under Windows, which is for now the only way I can get them to work. Not only do they have to be registered, they have to be self-registered during installation. This is because in addition to normal COM registration, the IME also needs to call RegisterProfile and RegisterCategories on the TSF. Now, self-registration is an option that is inaccessible specifically to .Net assemblies, which only do the former but not the latter two. So how should I get my IME registered, if it is a .Net assembly?

Technically I do not have to put the settings dialog box and the IME in the same program. They could be separate programs -- one reads the registry, the other writes to it. So, when a users wants to open the 'Settings' dialog box, the IME could simply instruct Windows to execute a separate program.

It does not feel very clean -- would it (execution of programs) work under Internet Explorer? Do I want the IME settings dialog box to be a modal dialog box over the Input Settings dialog box Nevertheless I think this is the way to go.

Windows 8 and Metro

Ah, the pain in the a** for users and developers alike, Metro.

In short, Metro apps are 'contained'. Or sandboxed. There are some restrictions on IMEs.

Apparently, even Google can't be bothered to make their software work. Google Pinyin only supports Windows up to Windows 7. It works in Windows 8, but not in Metro (Disclaimer: from initial observations only. Maybe it's supported.).

That is interesting, because to be honest, I don't even use a single Metro app (hear that, Microsoft?), not even the Start screen (I use Classic Shell). If Google can't be bothered, neither can I. Regarding project priorities, Metro support is very low priority for me.

Other Eurekas

Bitness

The IME modules are currently loaded as DLLs by the application they are used in. So for example, if I were debugging the IME, I would 1) run Notepad, 2) under Notepad, switch to the IME, 3) attach the Notepad process to the Visual Studio debugger.

This is why there are two versions of the binaries -- the 64-bit version and the 32-bit version, each to be used by applications of the same bitness.

Internet Explorer and File Mappings

It turned out that for some reason, Internet Explorer (perhaps because of some protection policies) does not allow attached DLLs to share file mappings with other software. The solution to this was to not provide a label when calling CreateFileMapping.