DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2344 Version: 1.3-current Patch in STR#2366 seems to fix: ALT+A -- works consistently regardless of caps-lock SHIFT+CTRL+A -- works consistently regardless of caps-lock CTRL+ALT+A -- works consistently regardless of caps-lock However: SHIFT+ALT+A -- (BAD) triggers as ALT-A when caps-lock is on. Probably a separate problem that needs addressing separately. Regarding the casing of how shortcuts appear in code (eg. FL_ALT+'A' vs. FL_ALT+'a'), search for the thread on the fltk.development, subject: "shortcuts: intended vs. actual behavior" Bill Spitzak's comment: ---- I think the desired behavior is to require FL_SHIFT if you want to force a shifted letter to match. If it not there then shift must not be held down. FLTK 2 does an exact match of the key plus shift flags, except case of letters is ignored (so "A" will match even though the keysym is "a"). If that fails it then tries matching the ascii text produced by the key (so a shortcut of "@" works even though the actual key is "2"). >> Greg Ercolano wrote: >> >> I'm trying to strengthen the docs on shortcut specifications, >> >> and am finding there's contradicting behavior with casing of >> >> the keyboard codes. (There's already an STR about this) >> >> >> >> What is the /intended/ behavior for shortcuts like: >> >> >> >> 'a' -- Should only lowercase 'a' trigger shortcut? >> >> Or both 'a' and 'A'? >> >> 'A' -- Should this imply Shift-A, or just 'a' too? >> >> FL_CTRL+'a' -- Should only allow Ctrl-A, and not Shift-Ctrl-A? >> >> FL_CTRL+'A' -- Should this imply Ctrl-Shift-A? Or only Ctrl-A? >> >> >> >> What I'd like to do is document the /intended/ behavior >> >> so bugs can be properly reported for contradicting behavior [..] ---- Link: http://www.fltk.org/str.php?L2344 Version: 1.3-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
