Hi,

First post, be gentle.

Im trying to make a Window in FLTK2.0 (DevPack version, Windows) that can receive both key(down) and keyup events.

My objective is to have a runtime table of 'hotkeys' the user can press to trigger the PUSH/RELEASE of a Button.

My first attempt used shortcuts in my Window, but it doesn't 'animate' the PUSH/RELEASE of the corresponding Button, and only fires a callback on PUSH anyway.

My second attempt subclassed Window, and tried to get the keystrokes in handle().
This failed, seems only Widget in focus() gets KEYUP events. I could however, get ALL the KEY events.

My third attempt subclassed Button, uses the hotkey map (key_2_cmd) to see if it has a defined hotkey, and if so, sends the appropriate PUSH or RELEASE event to the Window (via handle_ex - a custom function).

This works perfectly for SOME keys, but not others. I can use fltk::PageDownKey for example , but not fltk::PageUpKey. The keys available to me are consistent across multiple versions of Windows ...but only about half the keyboard. With the 'broken' keys, I get neither KEY or KEYUP events.

It appears that my Button is not receiving all the keys, only some. It also smells like a dirty hack based on guess work.

Does anybody know what I'm doing wrong, or if this is an 'undocumented feature' in FLTK2.

I've included the (not quite right) code, sorry for the length, it uses lots of buttons.

cheers,

Matt from Tasmania (scratching head).

Attached Files

source.zip (3.1 KB, 32 views)

FL_KEYBOARD events are usually only sent to the widget that has focus. If that widget does not use the event, they are resnt up the hierarchy, until a widget does. If no widget eats the event, they are resent as FL_SHORTCUT. Finally, if nobody used them, they are sent to whatever you defined with Fl::add_handler.

FL_KEYUP events are normally only sent to the focus widget and only if it used the corresponding keydown (at least that is the intention ;-). )

So you have two ways out: as soon as you get your key event, also set the focus to that widget. You should then get a keyup as well. Or watch events with add_handler and then set button colors accordingly. None of that helps though, if another widget with higher priority already uses your shortcut for something else.

Thanks for that.

I got it working by subclassing all my widgets and sending all KEY and KEYUP events back to the parent(). Some keys were still missing until I subclassed everything. I suppose this is because I was blindly ignoring the focus() issue.

I was still uncomfortable with my solution and hoped the forum might shed some light on a better way.

If I keep track of which Widget has focus() I can trap the pesky KEYUP event (add_handler - as you said) and greatly expand the Widgets can use.

I realise now that this was already documented, so I feel a little blonde.

Cheers!

No worries. UI programming is not easy, particularly if you try to get some extra effects going... .