From: Paul N on 5 Jan 2010 17:16 In my program, some of the time I allow the contents of a windows to be edited, which I do by covering the window with a multiline edit box. I have subclassed the edit box and examine the WM_KEYDOWN message, so that the user can end editing by pressing ESC. More recently I have added the facility that, if the user presses TAB while editing, the cursor will move to after the next colon in the text. Or the previous colon, if shift-tab is pressed. This is also done by intercepting the WM_KEYDOWN message. This worked all right at first, but then I fixed a bug elsewhere in my program - I had an accelerator for control-I and the TAB key was setting this off by mistake. That bug-fix has messed up my TAB-bing, in that now, when I press TAB, the cursor moves to the right place but also inserts a tab at that point. I don't want it to insert a tab there. What is the best way to deal with this? One possibility seems to be to add a "dummy" accelerator to swallow up the TAB, the way it was working originally, but this seems a bit messy. The alternative seems to be to intercept the WM_CHAR message if it is a tab. Is this the best approach? Should I compare the value with VK_TAB (which appears to have the right value, but only by coincidence, as the VK* values are supposed to relate to keys not characters), with 9 or with '\t' ? Would all of these also pick up shift-tab? Thanks for any guidance. Paul.
From: patrick on 7 Jan 2010 11:18 On 5 jan, 23:16, Paul N <gw7...(a)aol.com> wrote: > The alternative seems to be to intercept the WM_CHAR message if it is a tab. Is this the > best approach? Should I compare the value with VK_TAB (which appears > to have the right value, but only by coincidence, as the VK* values > are supposed to relate to keys not characters), with 9 or with '\t' ? > Would all of these also pick up shift-tab? Yes, handling WM_CHAR is standard.
From: Paul N on 7 Jan 2010 16:21 On 7 Jan, 16:18, patrick <patrick.beltra...(a)caramail.com> wrote: > On 5 jan, 23:16, Paul N <gw7...(a)aol.com> wrote: > > > The alternative seems to be to intercept the WM_CHAR message if it is a tab. Is this the > > best approach? Should I compare the value with VK_TAB (which appears > > to have the right value, but only by coincidence, as the VK* values > > are supposed to relate to keys not characters), with 9 or with '\t' ? > > Would all of these also pick up shift-tab? > > Yes, handling WM_CHAR is standard. Thanks Patrick. It seems to be working properly.
|
Pages: 1 Prev: How to keep a display turned off Next: Pipes - Named or Anonymous |