imacarthur wrote:
> Ah, right. Decoding keys from the numeric keypad... You need to take  
> account of the modifier bits... I'm not sure if/where all this is  
> documented, 

        I believe Fl::event_text() does what he wants.

        Docs for keyboard event handling talk about this, but the docs
        for Fl::event_key() don't, but probably should:
        
http://fltk.org/doc-1.3/group__fl__events.html#g12be48f03872da009734f557d1e761bc

        Also: docs for Fl::event_text() should probably be improved,
        as currently the 1.3.x docs indicate it's only for copy/paste:
        
http://fltk.org/doc-1.3/group__fl__events.html#g6647c55948fe1d8be9367267529e9c54

        Quoting:
            "Returns the text associated with the current FL_PASTE or 
FL_DND_RELEASE event."

        ..but the keyboard event docs say otherwise, which my tests confirm:

Keyboard Events
FL_KEYDOWN, FL_KEYUP
A key was pressed or released. The key can be found in Fl::event_key().
The text that the key should insert can be found with Fl::event_text()
and its length is in Fl::event_length().

        I've added the above to my combo docs patch STR#2226
        which I'll try to get around to this weekend.

PS. Anyone know if those crazy doxygen doc links that have all the
hex codes (above); do those remain consistent over time, or can those links
go stale whenever the dox docs get rebuilt? I wonder if there's a way to
get those to be more mneumonic? I *think* there's a dox command for tagging
or some such which we maybe should use to avoid the above obscure links,
as that would suck eg. for the newsgroup if those go stale, or worse, point
to the wrong docs over time.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk

Reply via email to