1. Intercept TAB key
- Posted by lpuster Sep 19, 2011
- 1301 views
I am using Win32Lib and Euphoria 3.1.1. While typing in an EditText or MleEdit control, the tab key inserts a tab code (9) into the text. I want to intercept the keystroke and setFocus to the next field instead. w32HKeyDown almost works, but the tab key has already placed the code in the text! Documentation seems to say that returnValue(-1) will "cause the application to ignore the keystroke" but the code goes into the text anyway.
2. Re: Intercept TAB key
- Posted by DerekParnell (admin) Sep 19, 2011
- 1234 views
I am using Win32Lib and Euphoria 3.1.1. While typing in an EditText or MleEdit control, the tab key inserts a tab code (9) into the text. I want to intercept the keystroke and setFocus to the next field instead. w32HKeyDown almost works, but the tab key has already placed the code in the text! Documentation seems to say that returnValue(-1) will "cause the application to ignore the keystroke" but the code goes into the text anyway.
The trick of using returnValue(-1) only works for the w32HKeyPress handler. It does not work for the w32HKeyDown handler.
3. Re: Intercept TAB key
- Posted by lpuster Sep 19, 2011
- 1214 views
The trick of using returnValue(-1) only works for the w32HKeyPress handler. It does not work for the w32HKeyDown handler.
Thanks Derek. I was mislead by the documentation, which says of w32HKeyPress: "Only "visible" keys are reported with this function. To trap "special" keys (such as the cursor keys), use w32KeyDown...". I guess it meant to say "Only keys that produce ASCII codes are reported with this function." I recommend the doc be changed.
4. Re: Intercept TAB key
- Posted by DerekParnell (admin) Sep 19, 2011
- 1177 views
The trick of using returnValue(-1) only works for the w32HKeyPress handler. It does not work for the w32HKeyDown handler.
Thanks Derek. I was mislead by the documentation, which says of w32HKeyPress: "Only "visible" keys are reported with this function. To trap "special" keys (such as the cursor keys), use w32KeyDown...". I guess it meant to say "Only keys that produce ASCII codes are reported with this function." I recommend the doc be changed.
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.
5. Re: Intercept TAB key
- Posted by lpuster Sep 20, 2011
- 1136 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?
