My application has a main form with its "IsMdiContainer" set to 'true'.

I create a form to serve as a child form, setting its "MdiParent" to the
main form before calling its "Show()" method.  The "AutoScroll" property is
set to 'false'.

My child form class has two scroll bars which I added manually; an
HScrollBar and a VScrollBar.  Each of these scroll bars has its "TabStop"
property set to 'false'.  (As mentioned above, the "AutoScroll" property of
the child form class is set to 'false'; I do not want to use the form's
automatic scroll bars.)

Any instance of the child form properly has its OnKeyDown() handler
triggered when the child form has focus and regular keys are pressed.

All works great -- until I press a cursor key (i.e., up, down, left, right).

When I press a cursor key, one of the scroll bars starts to scroll, and
starts to
flash!  When I release the cursor key, the scroll bar continues to flash,
and no
other key events are received by the child window.

Wait...  I just solved my own problem!

Override OnPreviewKeyDown(), and then disable each scrollbar (set its
"Enabled" property to 'false'), and call Invalidate(false) to put a repaint
message in to the queue for the form.  When the scrollbars are disabled, this
is evidently enough to prevent the cursor key from finding a scrollbar and
locking to it, starting the flashing, and capturing the input.  Upon repaint
we can set the Enabled property of the scrollbars back to 'true' if
appropriate.

Whew!  I thought I was going to have to implement my own "MDI" logic instead
of using the "IsMdiContainer" feature.  Wow, the worst part about Windows
Forms is the crazy logic concerning how cursor key events, mouse wheel
events, focus, and other things are handled...  What next?!

Anyhow, I am sharing my discovery for the benefit of others.

--- Colin