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.
Hmm - do you actually *know* this is slow? When I read this, if I’m honest, my first thought was “premature optimization”...
My experience suggest strongly that the simple way might well be more than fast enough, on any recent computer.
I’d strongly suggest trying the easy thing first, and only doing the complicated “manual” handling if it actually proves necessary (which I suspect it will not, TBH.)
OTOH, if non-EN-US keyboards prevent FLTK from using event_key() then I guess i'll be forced to look at event_text().
Indeed... amongst other things.
See attached example: US-English, German, French keyboards with one
example keypress in FLTK's test/keyboard, all on Linux (I didn't bother
to take macOS screenshots).
The actual keyboard I used was a German (notebook) keyboard, set up as
English (US) keyboard, i.e. the key I pressed would have been '/' on the
US keyboard, hence Fl::event_text() is "/" whereas Fl::event_key() is
minus ('-') which is the key on my German keyboard. This is a special
test case but there are many more reasons why one should prefer
Fl::event_text().
Note: in most (US-ASCII) cases Fl::event_text()[0] is the text
representation of the ASCII character, but with UTF-8 and such things
like German Umlauts (needed n scrabble games) things are different.
Comments are owned by the poster. All other content is copyright 1998-2025 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.
