🚀 go-pugleaf

My (hopefully right) conclusions and solution are
based on Peter Below's post in this thread
(in the Delphi newsgroups) http://tinyurl.com/cwjw
and by the code in control.pas

1-Normal keys:
Whenever a key event happens, the OS
sends a key message to the focused control. The
focused control checks if it's parent form has
KeyPreview set to true, and if so, passes the
key event to the form, before handling it itself.

2-Navigation keys (arrows, TAB, etc.)
The OS only sends key messages for these special
keys to the control if the control says it wants
them. The behavior will depend on the focused control.
A default Button doesn't ask for them, so
it never receives key messages for navigation keys,
thus the form never has a change to deal with them
when a button is focused (even if KeyPreview was set
to true).
A default edit control (edit, memo, rich edit) wants
arrow key events but not TAB key. The FormKeyDown
event handler might be used to catch the arrow keys
when an edit control has focus, but (unless the edit
control has WantTabs set to true) the FormKeyDown
will never see the TAB key event.

3-Unhandled navigation keys:
If a focused control doesn't handle a navigation
key event (any navigation key event for a button for
instance, or a TAB key event for a 'false' WantTabs memo)
then the Form uses the event to change the focus to
another control. This can happen because the control
sends a CM_DIALOGKEY message to the form in such cases.

Conclusion:
Normal keys and those navigation keys handled by
controls might be intercepted in the Form OnKeyDown
event (the form KeyPreview must be true).
Navigation keys that are not handled by a control
can be trapped at the form level if you intercept
the CM_DIALOGKEY message.

An example: a form with 4 buttons and a memo.

In unit.h:
private:  // User declarations
   void __fastcall CMDialogKey(TCMDialogKey &Message);
   BEGIN_MESSAGE_MAP
     VCL_MESSAGE_HANDLER(CM_DIALOGKEY, TCMDialogKey, CMDialogKey);
   END_MESSAGE_MAP(TForm)


In Unit1.cpp:
(Note: the code in FormKeyDown and in CMDialogKey
are basically the same. Could be moved to a single function.)
//--------------------------------------------------------
void __fastcall TForm1::FormKeyDown(TObject *Sender, WORD &Key,
			TShiftState Shift)
{
// here we trap normal keys and navigation keys handled
// by controls

Caption = "FormKeyDown";
Color = clRed;
switch (Key) {
   case VK_LEFT:
     Color = clWhite;
     break;
   case VK_RIGHT:
     Color = clBlue;
     break;
   case VK_UP:
     Color = clGreen;
     break;
   case VK_DOWN:
     Color = clYellow;
     break;
   }
}
//--------------------------------------------------------
void __fastcall TForm1::CMDialogKey(TCMDialogKey &Message)
{
// here we trap navigation keys which are not handled
// by controls
Caption = "CMDialogKey";
Color = clRed;
switch (Message.CharCode) { // note: the TCMDialogKey message
   case VK_LEFT:             // is a TWMKey message type
     Color = clWhite;        // Message.CharCode specifies
     break;                  // the virtual key code
   case VK_RIGHT:
     Color = clBlue;
     break;
   case VK_UP:
     Color = clGreen;
     break;
   case VK_DOWN:
     Color = clYellow;
     break;
   }
// let the form do its work
TForm::Dispatch((TMessage*)&Message);
}
//--------------------------------------------------------

When the memo has focus, its WantTabs is false and TAB
is pressed, then the CMDialogKey handler is fired.
Setting the memo WantTabs to true fires the FormKeyDown.

Comments and corrections are more than welcome.

Eudy