Tab Key

[Nicolás Avellaneda]

Hello,

Can any tell me if there is a way to trap the TAB key pressed over a
control and override the change of focus to the next control. Thanks.

[Charles Hacker]

Assuming your control is a TEditBox, then using a OnKeyPress routine do:

procedure TForm1.Editbox1KeyPress(Sender: TObject; var Key: Char);
begin
if key = #9 then { Tab key = CHR(9) }
key := #0;
end;

[lsoft]

Try to trap it in the overrided CMDialogKey method of the form. See the VCL
source, search for this method.

Nicolás Avellaneda <navel...@centrisa.com.ar> az alábbiakat írta a
következő hírüzenetben: 8a9ef7$gu...@bornews.borland.com...

[Nicolás Avellaneda]

Thanks, it works fine. But only one question:

Do you think is natural to Override a methos in a container (in this case
the form) to modify the behaviour of a child in this case an edit component.
Why i can't modify the class itself?????
For example WHY I CAN'T DO THIS:

TEit = Class (aClassID)

Protected
Procedure CMaMessage (Var Message:TSomeType); message
CMaMESSAGE;

Public

end;

and implement the event trap in the edit
classs......................................

lsoft <ls...@ax.hu> wrote in message news:8aa6ua$he...@bornews.borland.com...

[Peter Below]

In article <8ab8fm$is...@bornews.borland.com>, Nicolás Avellaneda wrote:
> Thanks, it works fine. But only one question:
> Do you think is natural to Override a methos in a container (in this case
> the form) to modify the behaviour of a child in this case an edit component.

The navigation between controls is a task of the form, not of the individual
controls. The edit control, for example, tells the message processing code
that it is not interested in seeing tab messages (in reponse to a
WM_GETDLGCODE message) so it will never get WM_KEYDOWN or WM_CHAR message for
a tab. Instead the message processing code (in forms.pas, part of the message
loop stuff in TApplication) will send a CM_DIALOGKEY message to the form,
which handles it to implement the navigation.

> Why i can't modify the class itself?????

You can, if you know how <g>. There are several possible openings. For a
single key i would use the CM_WANTSPECIALKEY message. The control gets this
for *every* key (with the exception of shortcuts, which are handled earlier)
and if it replies with message.result := 1 the key will be considered handled
and not be passed on any further. The message record for this message is
TWMKey, by the way. Since i haven't posted the following tour through Delphis
message processing for keys for some time you get subjected to it for good
measure.

the control with focus will not receive all keys. The Windows/VCL key handling
mechanism works like this:

1. you press a key.
2. a WM_KEYDOWN or WM_SYSKEYDOWN message is put into the applications
message queue.
3. the message loop code retrieves the message and, after some checks
for special treatments (e.g. for MDI) hands it to a VCL function.
4. The function converts the message to a CN_KEYDOWN message and sends it
to the control with focus.
5. The handler for this message in TWinControl first checks if the key
is a keyboard shortcut for a menu item on the controls popup menu (if
any), if not it checks all the popup menus of the controls parent
controls and finally the forms main menu (if any).
6. If it is not a menu shortcut the key event is next send as a CM_CHILDKEY
message to the control. The handler for this message in TWinControl does
nothing more than sending it to the controls parent. It will thus work
its way up the parent chain until it finally reaches the form. This
constitutes the first chance to trap the key event at the form level.
7. If the CM_CHILDKEY message is not handled by any receiver (none sets
msg.result to 1) the code in TWincontrol.CNKeyDown then asks the control
whether it wants to handle the key event. However, it does this only if
the key is one of the following: VK_TAB, VK_LEFT, VK_RIGHT, VK_UP,
VK_DOWN, VK_RETURN, VK_EXECUTE, VK_ESCAPE, VK_CANCEL, all other keys
will be delivered to the control without further checks.
CNKeyDown sends two messages to the control for these keys:
7a.CM_WANTSPECIALKEY
7b.WM_GETDLGCODE (which is the message Windows standard controls expect
and handle).
8. If the control does not express an interest in the key (Tedit controls
do not want VK_TAB, for instance) a CM_DIALOGKEY message is send to the
form for these special keys. The default handler for this message in
TCustomForm handles the navigation between controls in response to the
key events and marks the message as handled. This message is the second
opportunity to trap these keys on the form level. The default handler
broadcasts the message to all TWinControls on the form, this is the
way default and cancel buttons get aware of return and Escape key
events even if they do not have the focus.
9. If the key message is still not marked as handled (msg.result is still 0)
the code path returns to the message loop and the message is finally
handed to the API functions TranslateMessage (which generates a WM_CHAR
message if the key produces a character) and DispatchMessage (which sends
the key message to the controls window proc).
10. The controls handler for WM_KEYDOWN receives the message. The handler in
TWinControl calls the DOKeyDown method, passing the message parameters.
11. DoKeyDown checks if the parent forms KeyPreview property is true, if so
it directly calls the DoKeyDown method of the form, which fires the forms
OnKeyDown event. If the Key is set to 0 there, no further processing is
performed.
12. DoKeyDown calls KeyDown (which is virtual and can thus be overriden),
TWinControl.KeyDown fires the controls OnKeyDown event. Again, if Key is
set to 0 there, no further processing is done on it.
13. Code flow returns to TWinControl.WMKeyDown, which calls the inherited
handler. The key event finally gets to the default window function
this way and may cause a visible action in the control.

As you can see the path of a key message is quite complicated. If you press
the tab key in an edit control the message will get up to step 8 and then be
processed on the form level as CM_DIALOGKEY, it is marked as handled there, so
all the steps further down are not executed and the control never sees the
WM_KEYDOWN message for it, so its OnKeyDown handler never fires for a Tab.

The process offers the following points of intervention on the form level:

a) Application.OnMessage
This event is fired directly after the message has been retrieved from
the message queue in step 3, before anything further is done for it.
The event sees all messages that go through the message loop, not only
key messages.
b) CM_CHILDKEY
If you add a handler for this message to the form it will see all key
events with the exeption of menu shortcuts. Such a handler would see
all tab key events, but also many others.
c) CM_DIALOGKEY
If you add a handler for this message it will see all the keys mentioned
in step 7, unless the control wants to handle them itself. This handler
would see VK_TAB if the active control is not a TMemo with WantTabs =
True or a TRichedit or grid control, for instance. I think for your
purpose handling CM_DIALOGKEY would be the correct choice. Do not forget
to call the inherited handler or form navigation will chease to work.

Addendum: there is additional handling for WM_CHAR messages, too, which can
result in CM_DIALOGCHAR messages to the form.

Peter Below (TeamB) 10011...@compuserve.com)
No replies in private e-mail, please, unless explicitly requested!

Sent using Virtual Access 5.00 - download your freeware copy now
http://www.atlantic-coast.com/downloads/vasetup.exe

[Nicolás Avellaneda]

Thanks a lot peter, your answer and yor completly explanation of the key
process is good.

Nicolas Avellaneda