How to catch the key pressed in a context menu?

[wimjongman]

The main question is: How can I get the state of the shift key when populating a context menu.

My context menu must be populated based on the press of the shift key.

1. When shift is not pressed, basic options are shown
2. When shift is pressed, advanced options are shown

The only way I found to catch the shift key is to add a Display filter on the keyup and keydown events:

	Display.getCurrent().addFilter(SWT.KeyDown, e -> {
		if (e.keyCode == SWT.SHIFT) {
			fShift = true;
			System.out.println("Down");
		}
	});
	Display.getCurrent().addFilter(SWT.KeyUp, e -> {
		if (e.keyCode == SWT.SHIFT) {
			fShift = false;
			System.out.println("Up");
		}
	});

This works fine most of the time. However, as soon as the context menu is shown, the keyUp event is not processed.

This means that my fShift boolean stays true if I let go of the shift key when the context menu is shown.

See attached snippet. Is there another way to grab the shift key state when I am in my context menu?

ATest.java.txt

[iloveeclipse]

Have you tried https://github.com/eclipse-platform/eclipse.platform.swt/blob/master/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet25.java ?

Note: display filters shouldn't be used for such "trivial" things like listening on key events in your own widget

[wimjongman]

Have you tried

This is somewhat the same thing but the problem is that shell events don't trigger if the shell has lost and regained focus.

Otherwise, the behavior is the same. The event does not trigger when the context menu is up. Is the context menu parented in a different way?

I am on windows 11, Eclipse 22-06

Note: display filters shouldn't be used for such "trivial" things like listening on key events in your own widget

The thing is that I have 50+ views and viewers. To introduce the new behavior, I have to add listeners to each of them. I want to avoid that if possible. I figured that if I am quick in the filter, adding the filter would have no visible side effects.

I would be great to get this information from Eclipse/SWT in some way. e.g. SWT.getKeyboard().getState(SWT.SHIFT);

[wimjongman]

The same trick but now on shell. Notice that the listeners stop working if the shell loses and regains focus.

ATestShell.java.txt

[laeubi]

I have done something similar and ended up using a filter, but as you noticed some events are still "lost" because the native UI already handles them. But you can use some tricks, e.g look at the modifiers of mouse move events...

[wimjongman]

But you can use some tricks, e.g look at the modifiers of mouse move events...

That worked. Thanks, Christoph!