| |
| |
Update: with demo program ...
On 5/13/21 10:49 AM Albrecht Schlosser wrote:
On 5/12/21 12:13 PM Dave Jordan wrote:
App *app also contains an Fl_Group which contains > 200 subclassed
Fl_Boxes.
I have written no explicit event handling in the Fl_Group.
If I do, the Group is going to get /all/ the events before the Boxes
do, and that will open a whole 'nother can of worms.
Why? It could really be helpful if the group would get the events before
the children so you could filter yourself which events to propagate to
the children and which not to propagate.
...
Here it /might/ be useful to implement the handle() method of the parent
group so you can filter events and don't propagate FL_SHORTCUT events to
the children if you really care about that "inefficiency".
Note: I didn't show this in the demo program.
// And i suppose this is also the source of the UI problem,
wherein after all the searching about, if a shortcut
function involves another
// cell taking focus, the old cell will not receive FL_UNFOCUS
(leaving it highlighted).
Hmm, I believe this /should/ work. If you call take_focus() and the
focus is assigned to the other cell the current Fl::focus() widget
should IMHO get the FL_UNFOCUS event.
This focus handling stuff is demonstrated in the attached
handle_focus.cxx demo program. The focus widget is highlighted
(FL_YELLOW) and the box type of the widget below the mouse is changed to
FL_UP_BOX (which would normally also use a different highlight color).
You can type a, b, c, or d (lowercase) to change the focus to the named
box which is handled by the focus widget as FL_KEYBOARD event.
You can also type the uppercase characters A, B, C, and D to move the
focus to the respective cell. This is handled by an FL_SHORTCUT event
since uppercase letters are ignored by the focus widget. Note that FLTK
switches the case from uppercase to lowercase after an attempt to
deliver the uppercase FL_SHORTCUT event to /all/ widgets.
Losing the focus and getting it back can also be seen if you click on
another window and back on the test program.
@Dave: your UI issue (not clearing the highlight color when losing the
focus) might be caused by a missing redraw. If your window is resizable
you can see if this is the case when you resize the window because this
would likely redraw every widget.
--
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/c782cbe0-d7d2-f220-8224-f462c1cfc27d%40online.de.
[ Direct Link to Message ] | |
|
| |
