| |
| |
On 8/5/21 12:24 PM, Greg Ercolano
wrote:
[..]
Or I think the better approach might be to make your own
subclass of the hold browser
that /doesn't/ react to Ctrl+End, which should be easy to
do, and will guarantee it doesn't
steal the events you want.
In your subclass handle() method, you can check for Ctrl+End
and ignore the event
by just doing a return(0); when it's received. This will
eclipse the event from the base class
so it can't react to it. Pretty sure this would work: [..] i'm going with the below, it works so far
int Brwsr::handle(int e) {
if(e == FL_SHORTCUT) return EVNOTHANDLED; // (aka 0)
// process tab and shift-tab -- they give other widgets the focus
if(e == FL_KEYBOARD && (! (Fl::event_state() & (FL_CTRL | FL_ALT | FL_META)))) {
if(Fl::event_key() == FL_Tab) {
}
return Fl_Hold_Browser::handle(e); // let other events/keystrokes do whatever they want
}
There is also a callback, not shown, and I was not clear on whether it would play nice with the handle, but now it seems obvious :)
Thanks again Greg and everybody for insight. -dave
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/CAPdW6bJddVOB_P5D_ZBshoDeSFtKjDMUofR%2BQiZqBMMk5FqAQQ%40mail.gmail.com.
[ Direct Link to Message ] | |
|
| |
