From: Paul N on
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
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
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.