Unable to stop propagation

[GoogleCodeExporter]

Hello,

I am unable to stop key event propagation. I have dug through the source, but 
do not see any methods for doing so.

It would be very beneficial to be able to stop the event from propagating once 
captured.

Original issue reported on code.google.com by JhnC...@gmail.com on 8 Sep 2012 at 7:31

[GoogleCodeExporter]

Do you mean stop propagation of the event on the native system?

Original comment by a...@1stleg.com on 8 Sep 2012 at 9:18

[GoogleCodeExporter]

Hi, thanks very much for replying.

Yes, I would like to be able to catch a key event, and then (if possible) stop 
the event from continuing on the native system.

For example, lets say I have a word processor open. 
I have a program running using jnativehook, that captures certain keys and 
translates them into mouse movements.
The keys I press to move the mouse would move the mouse, but they would also 
type characters into the word processor.

I would like to prevent the characters from being typed in the word 
processor/etc by stopping the key event from propagating. 

Thanks for reading.

Original comment by JhnC...@gmail.com on 8 Sep 2012 at 9:46

[GoogleCodeExporter]

I am not sure how possible this will be.  There are a few of major hurdles that 
I can think of.  First, I am not sure if I can stop propagation on all native 
platforms.  Second, the native hooks do no block native event delivery.  When 
events are received, they are passed off to Java where they are queued in a 
dispatch thread.  This allows for unregistering the native library from a 
listener and for flushing the queue when it is unregistered.  Finally, native 
events are copied to Java so canceling the native event would require some kind 
of mapping between Java and native events.  

I am a bit busy at the moment but I will look at adding a feature like this in 
version 1.2.  If you have any experience with C/C++ on any of the supported 
platforms and don't mind digging around to figure out how to stop event 
propagation on Linux, OS X and/or Windows it would save me a lot of time.

Original comment by a...@1stleg.com on 10 Sep 2012 at 4:36

• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

It may not be feasible for this project, and that is fine. After thinking about 
what you are saying with the event queueing in java, this may be more trouble 
and time than it is worth, but thanks for investigating it.

Original comment by JhnC...@gmail.com on 13 Sep 2012 at 12:03

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by a...@1stleg.com on 3 Oct 2012 at 10:39

• Changed state: Accepted

[GoogleCodeExporter]

I did a bit of research on this and it does not appear to be possible on X11 
based targets.  Due to portability requirements, I will not be able to add this 
feature at this time.  If X11 or Wayland is eventually able to provide this 
functionality I will reopen this bug at that time.

Original comment by a...@1stleg.com on 3 Dec 2012 at 5:58

• Changed state: WontFix

[GoogleCodeExporter]

Issue 54 has been merged into this issue.

Original comment by a...@1stleg.com on 2 Jul 2013 at 4:36

[GoogleCodeExporter]

Original comment by a...@1stleg.com on 2 Jul 2013 at 4:37

• Changed state: New

[GoogleCodeExporter]

It's possible on the windows platform by not calling CallNextHookEx in the 
lResult callback

Original comment by mark.jeronimus@gmail.com on 22 Jul 2013 at 10:48

[GoogleCodeExporter]

I am going to add this functionality for Windows and possibly OS X in 1.2 but 
it will be 'undocumented' for the time being.  The long term goal will be to 
address the XRecord shortfall during a port to Wayland.  I should be done with 
a 1.2 developer preview for Windows in the next few weeks.  I will keep this 
bug updated with information as it becomes available.

Original comment by a...@1stleg.com on 22 Jul 2013 at 3:50

• Changed state: Accepted

[GoogleCodeExporter]

In which release we have the fix for that.

Original comment by manoj....@gmail.com on 2 Aug 2013 at 4:47

[GoogleCodeExporter]

1.2, I will update this bug in the next couple of weeks.

Original comment by a...@1stleg.com on 4 Aug 2013 at 7:46

[GoogleCodeExporter]

As of revision 755, event consumption now works for Windows.  You will need to 
do some careful reflection to make this work but it does indeed prevent 
propagation.  I will add some docs to the wiki about how to do this later down 
the road.  If you need help implementing a solution let me.  Instructions on 
compiling the trunk from source are available in issue 67.

Original comment by a...@1stleg.com on 4 Sep 2013 at 3:44

[GoogleCodeExporter]

I agree that we should have [stop event dispatching/propagation] for this 
toolkit.
I'm developing remote desktop. One options is that : each time new Desktop get 
input focus, it will got all keyboard events include special key stroke ( 
window, alt-tab, ctrl-esc ....). It like virtual desktop in virtual box .

Original comment by nvson...@gmail.com on 19 Sep 2013 at 1:35

[GoogleCodeExporter]

>> I agree that we should have [stop event dispatching/propagation] for this 
toolkit.

It is currently there for windows and probably will be for OS X.  The real 
problem is that consuming events from userland is not currently possible on 
Solaris, Linux or Unix.  See comment #7 for more information.  Until a more 
reliable method exists on supported platforms, this method will not be public 
API.  That does not mean that you cannot use the method and only support 
Windows and OS X from your Java application.  You need to do a couple of things 
for that to happen.  First you must call GlobalScreen.setEventDispatcher() and 
pass in a very special ExecutorService that  effectively does nothing.  By 
nothing I mean that the ExecutorService needs to execute its Runnable on the 
same thread as it was called from.  The second thing you need to do is set the 
NativeInputEvent.propagate to false using Java's reflection API.  I don't 
remember exactly how I did that in testing but it something like what I have 
here should do.  Right now the event is declared final when it goes into the 
eventExecutor so you probably wont be able to change it from there but you 
could try.  Your other option is to compile from source and patch public final 
void dispatchEvent(NativeInputEvent e).  Also note that boolean 
NativeInputEvent.propagate is probably going to become int 
NativeInputEvent.reserved with a mask of 0x01 for true and 0x00 for false.

        try {
            Field f = NativeInputEvent.class.getDeclaredField("propagate");
            f.setAccessible(true);
            f.setBoolean(e, false);
        }
        catch (Exception ex) {
            ex.printStackTrace();
        }

Original comment by a...@1stleg.com on 19 Sep 2013 at 3:10

[GoogleCodeExporter]

I have posted updated example code for this feature on the wiki:  
https://github.com/kwhat/jnativehook/wiki/Examples

As of this morning, this feature should fully work on Windows.  Support for OS 
X is half implemented and will arrive in the trunk in the coming days.

Original comment by a...@1stleg.com on 23 Apr 2014 at 6:31

• Changed state: Started

[GoogleCodeExporter]

Alright this should be resolved for Windows and OS X as of 
https://github.com/kwhat/libuiohook/commit/5f31e082134313727e3e62557368fcf7530d2
bf8

Original comment by a...@1stleg.com on 23 Apr 2014 at 9:35

• Changed state: Fixed

[GoogleCodeExporter]

Attached is a nightly containing the fix for Windows and OS X.

Original comment by a...@1stleg.com on 25 Apr 2014 at 1:30

Attachments:

• JNativeHook-1.2.0-20140424.zip