Ability to capture modifier keys (e.g. alt)

[tig]

I'm messing with MenuBar et.al. and am curious about something: Why does MapKey (and the rest of the call chain) filter out letting ProcessKey see just modifier key events?

For example, if we wanted MenuBar to highlight when a user presses alt like it does on Windows, we'd want it to be able to 'see' that the user has just pressed alt.

Would the world end if MapKey was modified to pass through shift-modifier keys?

[BDisp]

There really is a gap in that regard. Like using ControlV or ControlF that doesn't even work. I haven’t looked at it much yet. I just solved the Alt key and € key that was not working. My preference would really be to make the combination of the shift, ctrl and alt keys available separately from the other keys. Regarding the mouse, I introduced practically all the basic functionalities needed. Regarding the keys, I don't know if there are any limitations in their handling, some combinations can be managed by the OS itself and it may not be possible to change its behavior. It would be great to be able to improve the level of the keys control. Take a look at TextField where I implemented 3 key combinations to copy (Ctrl+Alt+C), cut (Ctrl+Alt+X) and paste (Ctrl+Alt+V).

[tig]

I just did a test where I modified MapKey in WindowsDriver.cs to pass just alt keypresses on.

It demonstrated pretty clearly that a new API will be required because existing ProcessKey implementations get confused.

I would suggest

public virtual bool KeyDown(KeyEvent keyEvent)

and

public virtual bool KeyUp (KeyEvent keyEvent)

Ala Windows' WM_KEYDOWN/WM_KEYUP.

Thoughts?

[BDisp]

And if neither the
public virtual bool KeyDown (KeyEvent keyEvent)
nor the
public virtual bool KeyUp (KeyEvent keyEvent)
were even captured, the
public virtual bool KeyPressed (KeyEvent keyEvent)
could be implemented as in the mouse event Pressed, Release and Clicked

[tig]

Yep. I just did a PoC to prove this works:

In this gif I do:

• Alt down/up
• Down
• Down
• Alt down/up

Proving that I could plum KeyDown all the way up to MenuBar.

Ignore the "About..." menu in this demo. That's my test case for enabling top-level menu items that don't have sub-items, but can just do an action.

KeyDown/KeyUp will be groovy, but for what I really want, I'm afraid it will require more complexity: I need the equivalent of GrabMouse for the keyboard...

What do you think about using a bool to indicate up/down vs. having two methods? e.g.:

/// <summary>
/// Method invoked when a key is pressed or depresed. 
/// </summary>
/// <param name="keyEvent">Contains the details about the key that produced the event.</param>
/// <param name="up">True if this is a key-up event. False if it is a key-down event.</param>
/// <returns></returns>
public virtual bool KeyPress (KeyEvent keyEvent, bool up)
{
	return false;
}

[BDisp]

Good job. The parameter up in KeyPress is not necessary because this event is only captured if we ignore both the key down and the key up, that is, it is only triggered after the key up, of course.
In KeyEvent it is necessary to include both the key that produces the event as well as the key modifiers, such as Alt, Ctrl, Shift as well as special keys.

[tig]

Some additional notes...

In reality, ProcessKey is mis-named. What it really does is is process keystokes, and in all implementations (Windows, Net, and Curses) gets called on key-up. Actually for Net and Curses it gets called when a keystroke happens because there is no concept of keydown/up events in those drivers. IOW, the only implementation where the whole keydown/keyup functionality will work is Windows.

This mutes my enthusiasm some, because I suspect it's a tenet of gui.cs to have apps work the same cross platform?

[BDisp]

Perhaps you are right. I think many of the complexities used should only work on windows :-)

[migueldeicaza]

Right, they should work cross platform, and I think that the way of handling this would be to introduce a new method "ProcessKeyDown" which might only be triggered on Windows. And we could flag this appropriately. Perhaps provide this not as a ProcessKeyDown, but a "WindowsKeyDown".

Anyways, what we could do in addition to this new method, is essentially allow the per-platform capabilities to be enhanced. So for example, the "Alt" processing key might be limited to Windows, and I think that it is ok that this is the case. On each platform, we can take advantage of the best that we can get.

[BDisp]

Also my opinion is to try to adapt to all platforms and the keys that do not exist in some or in others to replace with another combination that has the same behavior.

[tig]

Done. Closing.