| |
| |
On 5/13/21 8:57 PM Dave Jordan wrote:
>
> Thanks, Albrecht, for putting in as much effort as is apparent here.
Welcome!
> Below are comments, clarifications, and a few much simpler questions.
>
> On Thu, May 13, 2021 at 4:49 AM Albrecht Schlosser wrote:
Hmm, I can't see that implementing a handle() method in your own group
widget (derived from Fl_Group) would change anything of the internal
logic. An example handle method might look like this:
MyGroup::handle(int ev) {
if (ev == FL_SHORTCUT) {
// preprocess event, decide which widgets
// should get it, maybe ignore it ?
if (some_condition ...)
return 0; // do NOT process, ignore
else if (uppercase...)
return 0;
}
// Process all other events:
return Fl_Group::handle(ev);
}
Note that this handle method is designed to *filter* events so they
don't reach the children, hence Fl_Group::handle(ev) is called /after/
the filter mechanism decided to ignore some events.
This handle() method could be the only method you need to implement,
except maybe constructor and destructor. The only necessary change would
be to change Fl_Group to MyGroup in the parent group widget of your cells.
This should be transparent to the rest of the implementation -- but I
don't know your code...
im starting to like the idea of filtering this way
> > class Cell : public Fl_Box {
> >
> > int handle(int e) { return brd_handle(this, e); }
> > static int brd_handle(Cell *cell, int e);
>
> As Greg wrote, that's an unnecessary extra step, you don't need the
> static method brd_handle(). Just use Cell::handle() for your stuff.
>
> I have the vague idea that i'm telling the compiler not to include all
> the handling code in every instantiation.
That vague idea is wrong. Code is never included in object instantiations.
good to know -- changes implemented
In most cases it's more appropriate to test Fl::event_text()
perish the thought! The part of my event processing that needs to be as responsive as possible deals with individual keystrokes. If i have to start strcmping this input its going to ruin my day. OTOH, if non-EN-US keyboards prevent FLTK from using event_key() then I guess i'll be forced to look at event_text(). What about output, you may ask. If you know Scrabble and its ilk (which is what my app is all about), you know that there are typically wildcard tiles that are blank. But blank doesn't cut it for the UI, so I've already built the capability of mapping from any keystroke to any glyph that the user can compose.
Back to your question, short answer: that's what bit tests are used for.
Test specific bits...
int s = Fl::event_state() & (FL_SHIFT|FL_CTRL|FL_ALT);
Now s can only be one of 8 different values and you can proceed with a
switch/case:
examples of masking very helpful, thanks
The important point is not that you had these cases in your handle
method but that you returned 1 (EVHANDLED) which lets FLTK drop this
event after your handle method got it. Just logging the event is
supposedly not "handling" it, so you may eclipse these events from other
widgets that would otherwise handle them.
point well taken.
-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/CAPdW6bL-j4iPuG9EfHWo6q1ZrwKVxmJOnVEa9N9gqoNuYN2%2BCg%40mail.gmail.com.
[ Direct Link to Message ] | |
|
| |
