Added missing attachment (PDF).

On 5/16/21 11:12 PM Albrecht Schlosser wrote:

On 5/16/21 10:42 PM Ian MacArthur wrote:

On 16 May 2021, at 01:48, Dave Jordan wrote:

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.

--
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/7e06496d-e5d7-05b4-2cfd-42675df96d94%40online.de.