What were Get/SetMessageExtraInfo ever used for?

KJK::Hyperion asks, "Could you shed some light on Get/SetMessageExtraInfo? It's almost like nobody on earth used them, ever, and I can't get some sample code."

Yup, that's about right. Nobody on earth (to within experimental error) ever used them.

These functions were introduced on July 20, 1990 (I'm looking at the change history right now) at the request of what was then called the Hand-Writing Windows group, which shipped the first version of Windows for Pen Computing in 1992. The idea was that each input event from the custom pen hardware would have this extra information associated with it, and the software that converted pen input into strokes (and ultimately into gestures or characters via handwriting recognition) would use this extra information to guide the conversion process.

Seeing as Pen Windows died a hasty death, I think it's fairly accurate to say that nobody on earth will admit to having used these functions.

For those of you fortunate enough never to have been exposed to Pen Windows, here are some random tidbits of information.

First, applications needed to be modified to support pen input. In particular, edit controls did not accept text input from the pen. You had to replace them with one of the following:

  • Handwriting edit control (hedit). This accepted free form handwriting input.
  • Boxed edit control (bedit). This accepted handwriting input, but you had to write one letter per box. This constraint resulted in much better character recognition.

Both of these controls were significantly larger than the standard edit control. They needed to be, in order to give enough room for the user to write. This in turned means that you had to edit all your dialog templates and custom window layout to take into account the larger pen-aware controls.

And just changing your controls wasn't enough. You also had to write extra code to call various character recognition functions to get the user's pen input converted and recognized.

Here's an artist's conception of what the boxed edit control looked like:

D o g

That weird triangle-shaped thingie was, I believe, called the dinky. What did it do? Beats me.

There are still vestiges of the old Pen Windows product in the GetSystemMetrics function: Check out SM_PENWINDOWS.

(Note that the old Pen Windows product is unrelated to the current Tablet PC product, even though they both do handwriting recognition.)

Bonus chatter: The Windows touch team saw their opportunity and commandeered the extra info (perhaps resurrecting the ghost of Pen Windows) and use the extra info to specify the source of the input.

[Raymond is currently away; this message was pre-recorded.]

Comments (17)
  1. tabpill says:

    There is an internally maintained change history of Windows? Turn it into a public Wiki please.

  2. Gabe says:

    tabpill: I'm guessing that there is just a change log at the top of the source code file that implements those functions. Odds are the file was copied from the Win16 project into the WinNT project and the change log came with it.

  3. Yuhong Bao says:

    AFAIK, I think Pen Windows lasted long enough to be in Windows 95.

  4. Ens says:

    I assumed it was just a source control diff that he's looking at.

  5. Josh Einstein says:

    Was gonna say (before I read the bonus chatter) that I actually wrote an MSDN article that never got published describing how to use that extra info to make UI's that adapter to pen/mouse. The examples I gave involved growing splitters and spinners. It was very useful to have that extra info without all the overhead of actually accepting stylus input.

  6. Joshua says:

    I've got another for your basic ground rules for programming.

    • Do not modify a procedure while you are calling it. Do not unload the DLL either.
  7. Eduard says:

    Actually, I'm using this mechanism in a program (KatMouse) which routes mouse wheel messages to the window/control which the mouse is hovering over.

    In this context, could you or somebody explain why Windows is sending mouse wheel message to the control with the keyboard focus?

  8. waleri says:


    I won't be surprised if it turns out, that early version of mouse wheel simulates keystrokes, like pageup/pagedown or something like that. Mind, that this is only a guess.

  9. Bill says:

    @Eduard: You've asked the wrong question.  It should be: "Could somebody explain why Windows is sending input messages to the control with the input focus?"

  10. Eduard says:

    @Bill: Mouse clicks do not follow input focus, so why mouse wheel clicks?

  11. Eduard says:

    @Bill: Mouse button clicks do not follow input focus, so why mouse wheel clicks?

  12. 640k says:

    @Eduard: Depends on if you installed intellipoint or not.

  13. Bill says:

    @Eduard: Any mouse action that you bind to a button via Mouse Properties will be sent to the input focus.  However, Click, Right-click, and AutoScroll happen to also change the input focus.  It sounds like your question really is "Why does Windows lump scrolling with the majority of actions that do not change focus, instead of the three special actions that do change focus?"

  14. GregM says:

    "why Windows is sending mouse wheel message to the control with the keyboard focus?"

    Possibility 1: scroll messages are sent to the control with the keyboard focus

    Pros: works the same as arrow keys, page up, page down.  You can move your mouse cursor away from the window and still scroll where your text cursor is.

    Cons: unrelated to the mouse cursor position

    Possibility 2: scroll messages are sent to the control under the mouse cursor

    Pros: You don't have to give keyboard focus to a control in order to scroll it

    Cons: If your mouse drifts as you are turning the wheel, you can suddenly start scrolling a different window.  Doesn't work the same as pressing the arrow keys, page up, and page down.  It only works when your mouse cursor is over a window that can be scrolled.

    I think the pros of 1 far outweigh the cons of 1.  Remember also that mouse wheel scrolling was first implemented on windows that didn't understand it, so they had to use existing mechanisms for scrolling.

  15. Random832 says:

    "Any mouse action that you bind to a button via Mouse Properties will be sent to the input focus."

    But the mouse wheel is not a button [yes, there's a button under it, but it's not the one we're talking about]. And mouse movement* does not get sent to the input focus – it gets sent to the window under the mouse cursor [unless the cursor is captured].

    *And, no, wheel scrolling isn't the same thing as mouse movement, but it's not a button either, and the analogy is just as fair.

  16. Eduard says:

    It seems that all other GUI systems chose the second approach (Mac OS, KDE, Gnome) and I'm preferring it, too.

    It just seems more natural. To scroll a window with the mouse wheel in Windows, you have to first give it input focus by clicking it, which can have other unintended effects.

    It's also the case that more and more Windows applications choose to implement wheel scrolling independent from the input focus. I have not yet encountered a Mac or Linux application that chose the Windows way regarding mouse wheel scrolling.

  17. M1EK says:

    By the way, the OS/2 pen extensions worked on the normal controls (i.e. you could write directly into existing fields) – although this was difficult in practice.

Comments are closed.

Skip to main content