TAB key

[Gary Beene]

I just happened to read this older post. This seems to work for me in DDT (in the RichEdit subclass procedure). No special message loop required.

Function NewProc(ByVal hWnd As Long, ByVal Msg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
   Select Case Msg
      Case %WM_GETDLGCODE
           Function = %DLGC_WANTALLKEYS
           Exit Function
   End Select
   Function = CallWindowProc(OldProc&, hWnd, Msg, wParam, lParam)
End Function

[Chris Boss]

I know the technique I describe above works, since I have used it in my software.

A DDT app would require using a real message loop though to do this.

[Michael Mattias]

But sans IsDialogMessage(), <TAB> does not advance/retreat 'as expected.' (Not to mention, if this is DDT style I don't think you can disable IsDialogMessage).

Which may or may not be "okay" in this application.... then again, we're all looking at this application in a total void, since "code not shown."

[Chris Boss]

Actually the solution is quite simple.

No subclassing needed.

The TAB key action is not a default of Windows, but is the product of the IsDialogMessage function call in the message loop.

For the both the Edit and RichEdit controls do the following:

During the EN_SETFOCUS notification event, set a flag to indicate the control is an edit control and requires the TAB key.

During the EN_KILLFOCUS notification event, clear the flag

In your message loop code, when the flag is set (is edit control) do not call the IsDialogMessage API function, but only call TranslateMessage and DispatchMessage.

When the flag is not set call IsDialogMessage like normal.

[Chris Boss]

Brian, I sent you a private message explaining how to do it.

[Michael Mattias]

That behavior - "Tab goes to next control with WS_TABSTOP style (and Shift+Tab goes to previous control with that style) " - is the by-design behavior of Windows and the rich edit control.

To change that behavior (which may or may not be desireable) you will have to subclass the Richedit control and when you get WM_CHAR/VK_TAB you "do something else."

There are probably only about 6,312 examples here of subclassing controls to change default keystroke behavior, most being "change <enter> to do what <tab> does by default" but the same code is easily adapable to whatever behavior you would like.

MCM

[Brian Reynolds]

I am using a Rich Edit Control and want to TAB across the page.
If I use CTRL-I, it works okay but if I use the TAB key it moves to the next control.
What I can't understand is that when I trap the keys and use MSGBOX, I get the same number "9", whether it's the TAB key or CTRL-I.
Can anyone help me circumvent the TAB key?