I created an ActiveX DLL that contains a simple
TForm with a few edit controls on it. The form
is wrapped in a simple Automation object with
only one method (create and show the form).

When the ActiveX DLL is loaded into an MFC-based
application and the form is displayed, the TAB key
does not work.

For example, with one of the edit boxes focused,
pressing tab should advance focus to the next edit
control, but instead, the system just beeps. The
arrow keys work inside the edit controls, and the
problem appears to affect only the TAB key.

The same form works correctly when it is run in
a standalone .EXE, or when the ActiveX dll is
hosted by a Delphi-based client.

Any ideas?

In article <3717C22C.810F9...@worldnet.att.net>, Tony Tanzillo
(tony.tanzi...@worldnet.att.net) says...

I've only tried this on IE4/5, but search this group on Dejanews
(http://www.dejanews.com) for SetWindowsHookEx. I've given some
suggestions there.

M.

--
Ettertraktet kaffe, er det ekstra god kaffe?
mailto:martin.larsson*delfidata.no.NOSPAM
http://193.214.62.200/martin/

Thanks, but I'm not sure this is the same problem. In
my case, the TForm is a modeless window that is not a
child of the host's mainframe.  It is only in the host
application's process space, but has no owner, and its
Application.Handle = 0.

The strange part is that a TMemo on the same form
does get the TAB key and responds to it properly
(with WantTabs = True).

This suggests to me that the TAB key is being routed
through the TApplication window's wndproc for any
controls that do not want it.  I would much rather
find a solution that does not rely on subclassing or
hooking the host application's wndproc.