Cursor keys always scroll, even it the module has captured focus.
This makes modules like Fundamental “Notes” not work, as well as modules not released yet that we are working on.
That’s the last remaining bug introduced by recent event system changes, which is nontrivial and will probably take a few days to think it out.
Ah, cool. Glad it wasn’t an intentional feature. No worries.
I see that the latest v1 code lets Notes process they cursor keys. My module still can’t. I expect it’s because I use onHoverKey() to get my keyboard input? Any tips for how to grab the cursor keys now?
btw: new code requires that APP->foo be replaced by rack::APP->foo. I assume that’s an intentional change?
That’s odd, it should work for you. Post your event handler.
Yes, APP now requires the namespace if you don’t use using namespace rack;
I can provide something more isolated, but here’s a github link: https://github.com/squinkylabs/SquinkyVCV/blob/sq5/src/seq/NoteDisplay.cpp#L279
The outermost handler looks like this:
void NoteDisplay::onHoverKey(const event::HoverKey &e)
{
bool handled = handleKey(e.key, e.mods, e.action);
if (handled) {
e.consume(this);
} else {
OpaqueWidget::onHoverKey(e);
}
}
If a module is selected and consumes the SelectKey event, HoverKey won’t fire. If not, is your handler called?
Ah - interesting. I am doing some crazy stuff there. I’ll check it out and try to make it work. Tx again!
Sorry, been away for a while. I’m getting very strange keyboard events from cursor keys. Perhaps it’s the odd way I’m capturing the mouse? Problem is that I get the cursor L,R hover, I process it ok, and I consume the event. But then Rack scrolls left or right on top of that.
It’s odd that even though I select myself from the hover, the hover still continues to fire. I suspect that setting capture my self from the hover is not recommended, but I took that out and still VCV Rack is processing the cursors, along with me. Perhaps it’s related to the mysterious action==3 that I get?
check this out:
First, a hover left come in. I process it, then set capture, then
consume the event.
onHoverKey key=263, left=263 action=1
enter handle key: key=263, action=1
press=1, repeat=2
in KeyboarHandler, key left, will handle
handle key will capture mouse
handle key=263, left=263 will ret 1
Then, even though left has only been pressed once,
onSelectKey is called. event.action is 3, which is not defined in
glfw. Since I don’t recognice this action, I don’t consume the event.
onSelectKey key=263, left=263 even.action=3
enter handle key: key=263, action=3
press=1, repeat=2
handle key=263, left=263 will ret 0
After this I get a series of hover keys and select keys.
Again, user has only pressed and release left:
onHoverKey key=263, left=263 action=3
enter handle key: key=263, action=3
press=1, repeat=2
handle key=263, left=263 will ret 0
onSelectKey key=263, left=263 even.action=3
enter handle key: key=263, action=3
press=1, repeat=2
handle key=263, left=263 will ret 0
onHoverKey key=263, left=263 action=3
enter handle key: key=263, action=3
press=1, repeat=2
handle key=263, left=263 will ret 0
onSelectKey key=263, left=263 even.action=3
enter handle key: key=263, action=3
press=1, repeat=2
handle key=263, left=263 will ret 0
onHoverKey key=263, left=263 action=3
enter handle key: key=263, action=3
press=1, repeat=2
handle key=263, left=263 will ret 0
onSelectKey key=263, left=263 even.action=3
enter handle key: key=263, action=3
press=1, repeat=2
handle key=263, left=263 will ret 0
Other key, however, work just fine. hoveing tab key lets me capture it and process it. It still sends me that stream of action==3, so perhaps that’s not related to my issue.
action = 3 is RACK_HELD, which is a new feature for tracking held keys. https://github.com/VCVRack/Rack/blob/v1/include/event.hpp#L80-L93
ah - ok. Since I don’t recognize it, I’m ignoring it. Can’t (yet) figure out what the Notes module seems to handle this fine, but mine doesn’t. Should I be consuming this event?
What exactly are you trying to do? If you want the user to select a widget and use GLFW_KEY_LEFT etc, you need to use event::SelectKey. To prevent other widgets from consuming it (like RackScrollWidget) you need to consume it with e.consume(this). If you want the user to hover their mouse over your widget and press GLFW_KEY_LEFT, you need to use event::HoverKey and consume it.
It’s kind of weird, I admit. Originally I made users click on my editor widget and then I used select key events. But testers didn’t like it because they kept forgetting to click on it to select.
So - I started processing they hover key events. But if the hover key is one of “mine”, I not only consume it, but then I turn around and set capture on myself like so:
rack::APP->event->setSelected(this);
The idea is that I opportunistically grab the hovers, so people don’t have to click. But, then, I grab the capture so that now I really have the capture and it will still work if they mouse the mouse out of my widget.
Kind of odd, I admit, but @dlphillips likes it. It worked in V1 until they scrolling refactor.
Should work, but of course after you set your widget as selected, you should consume SelectKey events as well and consume those. So what exactly is not working? It’s hard to read the above details.
Sorry for this unclear report - I should have spent more time before posting.
If I just look at the key presses, what seems to be happening is that for both left/right cursor pressed OR hover, I process the event and then consume it. after that I get a bunch of hold message, but I don’t consume them.
The good thing is that I can see that I am processing the cursor keys in my widget - they move my cursor around like they should.
The bad thing is that VCVRack is also processing those keys to scroll the entire rack. Of course I don’t want it to do that.
It’s like your Notes module and my module both had the same problem before you refactored stuff and restored your note module to functioning, but mine still doesn’t work.
If nothing is coming to mind, it’s clear I need to just jump in and debug my widget. Clearly notes works, so I should be able to emulate that, then add my (odd) capture behavior.
I assume it’s OK for my widget to use this for consuming the event?
void NoteDisplay::onSelect(const event::Select &e)
{
updateFocus(true);
e.consume(this);
}
In other words, I don’t need to pass the outer widget - just the widget that is overriding the onXXX event handlers, right?
Ah, maybe this is why? I just added a widget to a test module with
void onHoverKey(const event::HoverKey &e) override {
DEBUG("onHoverKey");
e.consume(this);
}
and it successfully prevented the rack from responding to arrow keys. So looks like you should consume event::HoverKey if e.action == RACK_HELD && e.key == GLFW_KEY_LEFT etc. Note that this behavior is a bit discouraged because people scrolling the rack with arrow keys will be stopped when their mouse hits your widget, which would confuse me as a user.
Just a note: consuming event::Select has no effect, so it’s unnecessary.
Thanks for looking into this - your suggestion works great. And, yeah, I know this keyboard handling is a little strange. Perhaps I’ll make it an option before this strange module is released.