Behold the Table Driven Text Service, Part 4 (Specifying when to modify, if not how)

by Michael S. Kaplan, published on 2008/01/25 08:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/01/25/7227422.aspx

Prior posts in the series:

• 0 (You have to start somewhere)
• 1 (Starting with a dictionary simple in every way)
• 2 (Three ways to convert!)
• 3 (Where do keystrokes come in?)

Now at this point some of the basic ideas are here as well as three kind of illustrative but not terribly useful samples, and the obvious question to ask is what gets covered next.

To start, I'll clear up some of the mystery from Part 3:

At this point, you may be wondering about two more things -- the meaning of the INPUT keyword here, and the meaning of the number 0. The fact that every single text file on Vista includes these very same entries is just a special bonus to people trying to figure out the meaning without assistance or documentation....

The INPUT thing describes the functionality to use and I'll get to that eventually describing other options here.

And that 0 thing? The meaning is "handle all shift states". You can replace it with flags that can be added together (literally added, with a PLUS sign and everything). The full list of them is:

• TF_MOD_ALT
• TF_MOD_CONTROL
• TF_MOD_SHIFT
• TF_MOD_RALT
• TF_MOD_RCONTROL
• TF_MOD_RSHIFT
• TF_MOD_LALT
• TF_MOD_LCONTROL
• TF_MOD_LSHIFT
• TF_MOD_ON_KEYUP
• TF_MOD_IGNORE_ALL_MODIFIER
• TF_MOD_ON_KEYUP_SHIFT_ONLY
• TF_MOD_ON_KEYUP_CONTROL_ONLY   
• TF_MOD_ON_KEYUP_ALT_ONLY

If you ever had to deal with keystroke events, you might see where some or all of this is coming from. Essentially you can use these flags to limit when the TABLE DRIVEN TEXT SERVICE will be handling specific key strokes and when it will ignore them and let them get passed through to the underlying keyboard.

Unfortunately, the TEXT section does not give you a way to distinguish between what shift state(s) are being depressed - which means if you add entries for both a and A then you will get two items in the candidate list to choose from, rather than just one. The good news is that the presence of these modifier flags mean that a future release can fix this limitation since the DLL really is paying attention to what modifier key(s) are being pressed for filtering purposes and they are positioned to extend that code to modify potential candidates in the future.

So for now when I am building these text files, I simply act like the case does make a difference so that when/if they fix this bug everything will work, and in the meantime everything will still work (albeit more slowly since a candidate list will exist).

This "workaround" only affects the "case" distinction; there is currently no way to specify the other modifier states and there is no way to know what this syntax will look like when/if that limitation is addressed.

But if I ever do find out you (as my loyal readers) would be the first to know....

An interesting consequence is that you can literally add duplicates if you want to -- and they will just show up in the candidate list. Since filtering is done based on really any of the modifiers you specify (or no filtering if you use that 0 that the built-in ones seem to use), you can add the ALTGR choice in with the same candidate characters as the non-ALTGR version, and for now it will just be on the candidate list.

Easy!

You can also simply add pure duplicates with no plans to ever distinguish them further, giving people two options....

But whenever there is more than one option in a candidate list, the order of the list can be very important (for obvious reasons). This is specifiable in the [Configuration] section of the text file, with one of the following options:

Keystroke sort

Text candidate list item should sort by keystroke order.

Form of keystroke sort is:

KeystrokeSort = integer value

Where:     0     - turn off keystroke sort (default)

           Not 0 – turn on keystroke sort

Text sort

Text candidate list item should sort by text string order.

Form of text sort is:

TextSort = integer value

Where:     0     - turn off text sort (default)

           Not 0 – turn on text sort

When you have pure duplicate entries, neither option will help much since KeyStrokeSort will not distinguish so should keep them in the order of the text file, while TextSort will also not distinguish and should also order them by the order they are in the file. But when the entries are not duplicates you can see different results and it is worth trying both to see which order you prefer.

Next up, I'll cover some of the other settings in the [Configuration] section, or I might cover the language settings. Whichever one I don't do next will be done the time after....

This post brought to you by ④ (U+2463, aka CIRCLED DIGIT FOUR)

referenced by

go to newer or older post, or back to index or month or day