You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, I am mapping keys to other keys - so if I listen for 'f' and then use java.awt.robot to (robot) type 'g', this works fine. But if I listen for 'g' and (robot) type 'f', then the events seesaw back and forth forever.
This is also an issue if you sometimes need to pass through a key event (i.e. ignore it).
Thinking about this for a (short) while, how about an option to add jkeymaster ignored key events to the event queue. This might be through a sub class of the usual key events. Then, a capture of 'f' could raise an ignorable 'g' event - when ignored, 'g' would be typed as usual, by bypassing the event handler. The 'g' capture could also generate an ignorable 'f' key event.
of course, I have no idea what is going on 'under the bonnet' - so this could be a terrible idea...
For the second case (optional pass through), I can see two other options:
Allow the key listener to 'restore' a keyevent back into the event queue, so it proceeds to the next listener/s (so it doesn't get called again)..
Add a Conditional Key Listener that has the option of consuming the event - or leaving it in the queue - the equivalent of setHandled(true). Again, this only helps with pass through.
For the first case, the previous options could also work for simple cases with custom code to handle the case of 'ignore events I have just raised'.
Is this something that makes sense for jkeymaster to handle?
The text was updated successfully, but these errors were encountered:
Firstly, the key capture works really well.
However, I am mapping keys to other keys - so if I listen for 'f' and then use java.awt.robot to (robot) type 'g', this works fine. But if I listen for 'g' and (robot) type 'f', then the events seesaw back and forth forever.
This is also an issue if you sometimes need to pass through a key event (i.e. ignore it).
Thinking about this for a (short) while, how about an option to add jkeymaster ignored key events to the event queue. This might be through a sub class of the usual key events. Then, a capture of 'f' could raise an ignorable 'g' event - when ignored, 'g' would be typed as usual, by bypassing the event handler. The 'g' capture could also generate an ignorable 'f' key event.
of course, I have no idea what is going on 'under the bonnet' - so this could be a terrible idea...
For the second case (optional pass through), I can see two other options:
For the first case, the previous options could also work for simple cases with custom code to handle the case of 'ignore events I have just raised'.
Is this something that makes sense for jkeymaster to handle?
The text was updated successfully, but these errors were encountered: