Modifier key sends key on mouse action

[RDGreen]

I'm new to this forum but have been using XMBC since v2.5 now. Love it!
But somehow, XMBC is not behaving as I'd expect it to. Here's what's happening:

• I defined the modifier key (say SHIFT) to activate Layer 2
• in Layer 2, I assigned the action "Copy (Ctrl+C)" to the mouse's Tilt Wheel Left and the action "Paste (Ctrl+V)" to the mouse's Tilt Wheel Right
• I save the settings, switch to my application (say Firefox), highlight some text, press SHIFT and tilt the mouse wheel left

Now, instead of copying the text, it's launching Firefox's Inspector! Why? Because the shortcut for the Inspector is SHIFT+CTRL+C, and those seem to be the keystrokes the XMBC is sending! I've tested this with other modifier keys and other applications as well: same phenomenon. The only way to get the copy/paste function working is to assign it to Layer 1, but that's not why I'd use XMBC.

Can you help unravel this?
Best regards,
Russell

[phil]

The problem with modifier keys is that the key is still held down. XMBC is not sending shift, your keyboard is!
Unfortunately, without blocking the key (which would stop shift working) there isnt much that can be done about that!

[RDGreen]

Thanks for your prompt reply, Phil!
Let me get this straight: XMBC offers modifier keys to swith layers per application, but it can't intercept the modifier key being pressed? That would mean, that an action would only lead to a reliable result if the action itself ignores key input, e.g. Magnifier on/off. Otherwise, I get whatever the combination of modifier key + action key results in...
Do you have any recommendation as to how to work with layers & modifier keys? Are there plans to implement this functionality?
Looking forward to your reply.
Best,
Russell

[phil]

Modifier keys, right now, are "global, not application specific.

When you hold down a modifier key, that key is still presented to the focused window and is still visibly held down when getting the keyboard state. I dont know if this can even be blocked - GetKeyAsync() call that is often used queries the keyboard state at a lower level than I could block in a hook.

Its quite possible that the only place this could be done differently, is the keyboarddriver itself and as XMBC is a use rmode program it has no influence over drivers.

Even if it were possible to block the key, that would mean the key never made it in any circumstance - clearly not ideal to always block CTRL or SHIFT etc!

There are several possible solutions to this although none of them are likely because of the effort involved, even if it were possible to do (and thats not clear)....

1. throw it away if the key is held for a certain period of time (thus allowing a normal keypress through and to not modify the layer).

The problem with this is that XMBC would have to wait to decide if its genuinely a modifier or just a normal key press. It wouldn't work well for any keys like CTRL, SHIFT, ALT which you often hold down in combination with another key. Also, it would have to re-inject the key if it decides its a genuine key press.... This causes implications as some applications (many games) block injects keys (that use the SendInput API).

2. make modifier keys application profile specific, so you can choose a key that will not matter if it gets thrown away.

The problem with this is is
a) complexity in XMBC. The more complex, the more change for error and the more time I have to devote to it (and being a hobby, I just cant afford to commit a lot of time to it).
b) you are still faced with a tough choice as to which keys could be used.

Thanks,
Phil

[RDGreen]

Thanks for the elaborate reply, Phil. At least I'm now sure that it's not a local problem or my personal incompetence.
The programm, though, suggests that I can

1. a) (temporarily) switch to a layer with a key-combination,
   b) invoke a predefined action using the mouse-buttons and
   c) return to the initial state.

This (for now obvious reasons) only reliably works with a limited number of functions, i.e. those that neglect the keystroke(s) sent.
The only workaround that I can seemingly apply is using the XMBC global hotkeys, i.e.

1. a) (permanently) switching to layer 2 with the layer-2-key-combination
   b) invoking the action and
   c) returning to layer 1 with the layer-1-key-combination.

It's not really that elegant, but does the job.
Maybe a word of caveat in the setup windows / manual or elsewhere would be helpful.
Best regards,
Russell

[phil]

Thinking about it a bit more, you could also use the global hotkey and then have the layer return to default after a time period using the "Switch to <layer x> after <y> seconds" on the layer tab?
(this is already do-able).

Actually thinking about it, now I have the auto-return options on the layer, it almost makes the layer modifier keys redundant anyway... hummmm....

Thanks,
Phil

[RDGreen]

Thinking about it a bit more, you could also use the global hotkey and then have the layer return to default after a time period using the "Switch to <layer x> after <y> seconds" on the layer tab?
(this is already do-able).

I'm sure there are scenarios where this option would make a lot of sense, assuming that the set time applies to all actions in that layer.

Actually thinking about it, now I have the auto-return options on the layer, it almost makes the layer modifier keys redundant anyway... hummmm....

Let me be frank about it: I don't think global keys should supersede the modifier keys. The majority of the modifier keys (SHIFT, ALT, CTRL, including any combination of) should do exactly one thing: extend the amount of functionality that can be triggered using a keyboard without needing a separate key. XMBC provides an elaborate list of actions that can be assigned to a button. Now doesn't it seem obvious to link those functions (e.g. CTRL + C, CTRL + V) with a modifier key to gain an enhanced productivity experience when using keyboard and mouse in sync?
Maybe in future versions...

[phil]

At the end of the day, XMBC is limited here by the architecture of windows, what I can hook into and therefore what is possible or sensible to block.

Without getting into drivers which is not my area of expertise, nor practical, I dont think there is much that can be realistically done to improve the way it currently works.

If an application (or windows) is looking for CTRL+C and your also holding down another key, then its going to see that The simple answer is to find a key that does not interfere, but again, realistically that's not easy in most cases.

[RDGreen]

Thanks for your insights again, Phil. With that, I think I'll close this thread.
again: a word of caveat could serve helpful to other XMBC users...
Best,
Russell

[RDGreen]

Addendum:
I found a bit of a workaround by using the CTRL key to activate layer 2 and the ALT key to activate layer 3. Of course I have to watch out that these keys do not conflict with any keystrokes sent (Simulated Keys pressed).