找到一篇英文资料，原因说的很明白了，你可以看看<br>Is there Any way to Capture the Tab Key? <br><br>Several, in fact. The problem is to distinguish tab keys that come from <br>your scanner from those the user creates by pressing the tab key. <br><br>If the active control is a button or Tedit control (which do not process <br>tab themselves) then the form will get the key in the form of a <br>CM_DIALOGKEY message. <br><br>Let's see, i have not posted this for some time and it is a bit hard to <br>find in the archives, so, enjoy <g>. <br><br>The control with focus will not receive all keys. The Windows/VCL key <br>handling mechanism works like this: <br><br>1. you press a key. <br>2. a WM_KEYDOWN or WM_SYSKEYDOWN message is put into the applications <br>message queue. <br>3. the message loop code retrieves the message and, after some checks <br>for special treatments (e.g. for MDI) hands it to a VCL function. <br>4. The function converts the message to a CN_KEYDOWN message and sends it <br>to the control with focus. <br>5. The handler for this message in TWinControl first checks if the key <br>is a keyboard shortcut for a menu item on the controls popup menu (if <br>any), if not it checks all the popup menus of the controls parent <br>controls and finally the forms main menu (if any). During this process <br>the forms IsShortcut method is called and fires the OnShortcut event. <br>IsShortcut also asks all actionlists on the form if one of their <br>actions <br>wants to handle the shortcut. IsShortcut and the OnShortcut event <br>constitute the first chance to intercept the key at the form level. <br>6. If it is not a menu shortcut the key event is next send as a <br>CM_CHILDKEY <br>message to the control. The handler for this message in TWinControl <br>does <br>nothing more than sending it to the controls parent. It will thus work <br>its way up the parent chain until it finally reaches the form. This <br>constitutes the second chance to trap the key event at the form level. <br>7. If the CM_CHILDKEY message is not handled by any receiver (none sets <br>msg.result to 1) the code in TWincontrol.CNKeyDown then asks the <br>control <br>whether it wants to handle the key event. However, it does this only if <br>the key is one of the following: VK_TAB, VK_LEFT, VK_RIGHT, VK_UP, <br>VK_DOWN, VK_RETURN, VK_EXECUTE, VK_ESCAPE, VK_CANCEL, all other keys <br>will be delivered to the control without further checks. <br>CNKeyDown sends two messages to the control for these keys: <br>7a.CM_WANTSPECIALKEY <br>7b.WM_GETDLGCODE (which is the message Windows standard controls expect <br>and handle). <br>8. If the control does not express an interest in the key (Tedit controls <br>do not want VK_TAB, for instance) a CM_DIALOGKEY message is send to the <br>form for these special keys. The default handler for this message in <br>TCustomForm handles the navigation between controls in response to the <br>key events and marks the message as handled. This message is the third <br>opportunity to trap these keys on the form level. The default handler <br>broadcasts the message to all TWinControls on the form, this is the <br>way default and cancel buttons get aware of return and Escape key <br>events even if they do not have the focus. <br>9. If the key message is still not marked as handled (msg.result is still <br>0) <br>the code path returns to the message loop and the message is finally <br>handed to the API functions TranslateMessage (which generates a WM_CHAR <br>message if the key produces a character) and DispatchMessage (which <br>sends <br>the key message to the controls window proc). <br>10. The controls handler for WM_KEYDOWN receives the message. The handler <br>in <br>TWinControl calls the DOKeyDown method, passing the message parameters. <br>11. DoKeyDown checks if the parent forms KeyPreview property is true, if so <br>it directly calls the DoKeyDown method of the form, which fires the <br>forms <br>OnKeyDown event. If the Key is set to 0 there, no further processing is <br>performed. <br>12. DoKeyDown calls KeyDown (which is virtual and can thus be overriden), <br>TWinControl.KeyDown fires the controls OnKeyDown event. Again, if Key <br>is <br>set to 0 there, no further processing is done on it. <br>13. Code flow returns to TWinControl.WMKeyDown, which calls the inherited <br>handler. The key event finally gets to the default window function <br>this way and may cause a visible action in the control. <br><br>As you can see the path of a key message is quite complicated. If you press <br>the tab key in an edit control the message will get up to step 8 and then <br>be processed on the form level as CM_DIALOGKEY, it is marked as handled <br>there, so all the steps further down are not executed and the control never <br>sees the WM_KEYDOWN message for it, so its OnKeyDown handler never fires <br>for a Tab. <br><br>The process offers the following points of intervention on the form level: <br><br>a) Application.OnMessage <br>This event is fired directly after the message has been retrieved from <br>the message queue in step 3, before anything further is done for it. <br>The event sees all messages that go through the message loop, not only <br>key messages. <br>b) The forms OnShortcut event. <br>c) CM_CHILDKEY <br>If you add a handler for this message to the form it will see all key <br>events with the exeption of menu shortcuts. Such a handler would see <br>all tab key events, but also many others. <br>d) CM_DIALOGKEY <br>If you add a handler for this message it will see all the keys mentioned <br>in step 7, unless the control wants to handle them itself. This handler <br>would see VK_TAB if the active control is not a TMemo with WantTabs = <br>True or a TRichedit or grid control, for instance. I think for your <br>purpose handling CM_DIALOGKEY would be the correct choice. Do not forget <br>to call the inherited handler or form navigation will cease to work.
