Re: Intercept TAB key
- Posted by lpuster Sep 20, 2011
- 1138 views
Yeah, I know its a bit hard to read. I wrote "visible" in quotes to give a hint that it wasn't quite literal. However, the set of ASCII codes is not quite right either as some of those are not passed to KeyPress and some non-ASCII codes are passed. In general, its those characters that take up space in a byte-size character text file, which includes SPACE, TAB, and CARRIAGE-RETURN, but not BACKSPACE, DEL and some other control-characters. The extended-ASCII characters are passed; those in the range 0x80 to 0xFF inclusive.
Thanks again. I noticed that when I press TAB or Shift-TAB, the shift key status reported by setHandler is always 0. Running further tests, I discovered that Return, and Shift-Return are reported correctly, but Ctrl-Return is reported as a newline (10) followed by a backspace(8). Weird. I also noticed that returnValue(-1) suppressed the character being placed in the edit control, but did not affect Windows processing. The TAB and Shift-TAB still shifted focus anyway. Fortunately, that's what I wanted.
Properly documenting Win32Lib is a daunting project. Have you given thought to creating a WiKi in the style of Wikipedia that everyone could submit to that would grow to be a full documentation of Win32Lib, including examples, tips, and tricks? For example, I needed to modify the default attributes for editText. I examined the source to see how and, amazingly, I discovered if flags is a SEQUENCE then it is used INSTEAD of the defaults. An undocumented feature. See what I mean?
