Hot Keys and altGr


The earlier post, RichEdit Hot Keys, lists all built-in RichEdit hot keys. In particular, it lists a popular hot key for typing the Euro (€), ctrl+alt+e, which works for some languages, such as US English. A problem may arise when altGr+e is assigned to some other character, such as é in Spanish keyboards. This is because altGr generates a left ctrl + right alt key down combination, instead of a right alt key down combination. RichEdit avoids a conflict by not treating left ctrl + right alt key combinations as hot keys. So with RichEdit and Word, it’s easy to insert both € and é using a Spanish keyboard. In contrast Notepad, PowerPoint and Excel insert é for both left ctrl + left alt and for left ctrl + right alt on Spanish keyboard layouts and they don’t insert anything for either on the standard US English keyboard layout.

You can even know the difference between altGr and left ctrl + right alt. Here’s how. In general pressing the left alt key sends a WM_SYSKEYDOWN message with wparam = VK_MENU and the KF_EXTENDED flag (lparam bit 24) set to 0. On keyboard layouts that don’t have altGr combinations, pressing the right alt key sends a WM_SYSKEYDOWN message with the KF_EXTENDED flag set to 1. The KF_EXTENDED flag tells you the difference between left and right, something every child should know.

Pressing a left/right ctrl key sends a WM_KEYDOWN message with wparam = VK_CONTROL and the KF_EXTENDED flag = 0/1, respectively.

On keyboard layouts that appropriate the right alt key for altGr, pressing altGr sends both a WM_KEYDOWN message for a left ctrl and a WM_KEYDOWN message for a right alt. Since the right alt key down message is WM_KEYDOWN rather than WM_SYSKEYDOWN, you know it’s an altGr and not the regular right alt key. Furthermore on such keyboard layouts, you can’t use the right alt key to access menus since it doesn’t generate a WM_SYSKEYDOWN message.

As a result, it’s easy to treat leftctrl+leftalt+e differently from altGr+e. I tried out this methodology with a Spanish keyboard, for which altGr+e gives é. Sure enough leftctrl+leftalt+e inserts € and altGr+e inserts é. You can have your cake and eat it too! But it’s probably good enough just not to use left ctrl + right alt for ctrl+alt hot keys which is the approach RichEdit has followed for years.

A question for future program design is whether altGr is even a good thing. On soft keyboards, you don’t need altGr since you can hold down a key to access a surround menu of related characters. But the need to enter more characters than given by the usual keyboard keys + shift hasn’t changed. This is true of European languages and even of English, since English includes many accented words imported from other languages. It’s even truer for math, which has a large character set. So for hard keyboards, more “shift” keys are better than fewer and appropriating the right alt key as altGr is a useful aid in accessing larger alphabets.

Occasionally I think of how silly it was for Apple to have had only one mouse button. The rationale was that people were incapable of handling more than one button. But can any of us imagine having only a single mouse button today? Meanwhile many people are musical and musical instruments often involve chording. With practice, people can do amazing things and keyboard chording of various kinds can give access to very large sets of characters. People without the inclination and/or dexterity to use hot keys aren’t forced to use them. But other people at least have simpler ways to enter some of the less common characters for their language(s) than using an insert-symbol dialog or entering the Unicode value for a character and typing alt+x to convert the value to the character. altGr doesn’t give access to that many more characters, but it does allow alphabetic and Indic languages to be typed without resorting to more exotic input methods.


Comments (6)

  1. Andreas Rejbrand says:

    Thank you for an interesting post. I have two off-topic questions about the formulae editor in Microsoft Word. Especially one of them seems to fall within your area of expertise.

    1. If a page break occurs at a soft line break within a formulae inside a boxed paragraph, an unexpected (and highly unwanted) "gap" in the box occurs above the last soft paragraph before the page break, see <english.rejbrand.se/…/msword.asp. Is there a workaround?

    2. It is common to include an "explanation" between two relational operators, as in <privat.rejbrand.se/msword-eq-step-expl.png>. In Swedish undergraduate mathematical education, it is common to use solidus (/) to enclose the explanation (instead of vertical bars as in the screenshot). As far as I can tell, this is not possible in Microsoft Word, is it? I have seen people use truly awful workarounds (fractions with empty denominators) which are semantically dreadful and also produce very awkward spacing. Is there some natural way to use solidi in this way?

  2. Andreas Rejbrand says:

    (Sorry, "formulae" should be "formula". And you have to remove the ">" from the URLs.)

  3. Tom says:

    I see that the Office 2016 preview is now available. Are there any major changes to Math handling that make this an essential download? I don't suppose native equation numbering has been added?

  4. MurrayS3 says:

    A couple of math improvements have been added to Word 2016 and PowerPoint 2016 including the equation-array equation number placement on the right side as in OneNote 2013. This doesn't do the equation numbering for you, but at least you can stick whatever you want flushed over to the right margin. The input for this is described in Unicode Technical Note #28, Section 3.21 Equation Numbers. At least it's a start 🙂 If you insert an AutoNum field (Insert/Quick Parts/Field…) into what you flush right, Word will autonumber it for you and you can use bookmarks to refer to the equations. I'll write a post about it pretty soon.

  5. Tom says:

    That does sound like a worth while improvement. Certainly better than using tables, and should work with existing equation numbering macros. Thanks. Has PowerPoints equation handling been brought closer into line with Word's? I've noticed in the past both that PowerPoint displays some things differently (e.g. dd is double struck in PowerPoint, but not in Word) and that PowerPoint's handling is rather more prone to crashing with big equations than Word's.

  6. MurrayS3 says:

    Re Andreas' comment, it's easy to insert any operator into a math zone and have it treated as an ordinary character: insert a backslash followed by the operator. So / inserts a / that won't be treated as a fraction build-up operator.

    I've reported the box bug Andreas mentions.

Skip to main content