Arrow keys aren't handled in onHoverKey() in Rack 2

So I had this thread which helped me figure out some keyboard shortcuts for Rack v1. However, some are now broken. Specifically it’s the arrow keys that won’t execute my code and instead will pan the screen around. I’m using consume() so I don’t understand why Rack is still using my shortcut. Here’s the code in question:

It would be jarring to the user if arrow key rack scrolling was interrupted when their cursor happens to travel over a certain module.

Why not consume them only when a widget is selected on your module panel?

Ok that works much better. I’m using onSelectKey for those events now, thanks.

Ok it works, but I noticed that once I click on a knob or button, it no longer works. It’s as if the onSelectKey() is done. Why does it do this? Is there a way to keep it active?

Hi Andrew, from a TransparentWidget, I use onHoverKey() as text input entry, but Backspace keypress always removes the module from the rack.

VCV Rack 2 (v2.2.3 preview)

	void onHoverKey(const event::HoverKey& e) override {
		if (e.key == GLFW_KEY_BACKSPACE) {
			e.consume(this);
			return;
		}
		int shift;
    if (module) {
...

does nothing about Backspace keypress.

Now I’ve tested via onSelectKey(), like this:

	void onSelectKey(const event::SelectKey& e) override {
		if (e.key == GLFW_KEY_BACKSPACE) {
			e.consume(this);
			return;
		}
		TransparentWidget::onSelectKey(e);
	}

Same results, module is always deleted/removed from rack.

e.consume(this) seems unefficient, or I’m wrong somewhere else.

I don’t know onSelectedKey() is doing exactly (not documented in API, such other methods), but it doesn’t reply on keypress (using debug).

Also, please consider to remove Backspace key as module deletion, Delete key is enough IMHO, I don’t know why module deletion needs two different (direct) keys.

Please help! TIA

OK, a little about the focus hierarchy in the GUI would be nice. The Window passes on to the Module which passes on to the Widget. If the Window consumes the event the Module never gets it. If a Widget has focus, the Module (container) may or may not get it (hover versus selected). It seems counter intuitive that a Module is not selected when one of its contained Widget controls is selected.

So Hover: The key event goes from big to smaller Widget under the mouse cursor, and can be consumed to stop.

So Selected: The mouse click “key-ish” event goes down the Widgets to the smallest focusable Widget and sets selection focus. A later key event then checks for focused Widget. Then it’s confusing as multi-module selections can happen.

1 Like

Hello Simon, thanks for your reply!

If I understand correctly, the Window you’re mentioning is the whole current rack, aren’t?

I presume onSelectKey() means while the widget is selected first? I’m right, or not?

I’m in standby for this weekend (yep, I try to have a normal social life) - Thank you so much, again, and have a nice weekend too!

may not help, but my ancient Seq++ module a) uses arrow key, and b) has full keyboard remapping via a JSON file. You can find it in the library, or here: SquinkyVCV-main/sq2.md at master · kockie69/SquinkyVCV-main · GitHub

1 Like

Thanks Bruce, I’ll take a look ASAP (today Sunday I’m with my family).

1 Like