>Zlatin,
>
>>
>>So, Visual FoxPro HWND control is hosted in its own window. Other ActiveX controls like the TreeView control also are hosted in own windows. However we do not experience such problems with these controls. So it is our control and FoxPro doing something "wrong". I need to figure out what is this and how to prevent it.
>
>I've never tried writing a visual ActiveX control, so I don't even have a clue as to what's happening here.
>
>>
>>Yes, this is what we do now... We check the BaseClass of the ActiveForm property... but it is dirty code and does not conform to what VFP help says about the ActiveForm property.
>
>Sometimes the documentation is wrong (although I think it's more a difference in your ActiveX in this case). Sometimes we have to write code that isn't very pretty. *s*

David,

Yuppers! I've found that some ActiveX controls (like the ListView and TreeView) don't affect the ActiveForm property. Others, such as the MS Toolbar, do and end up as the ActiveForm.

My hunch (and it's no more than that) is that it has to do with the nature of the control itself. Taking the Toolbar as an example, the most significant difference that I see is that the icons shown on the buttons can change depending on whether or not the button is disabled, enabled, "hot" (mouse over them), or "cold" (enabled but mouse not over them). The guess is here that this is goofing up the normal message processing that occurs otherwise.

The only (and I must admit, rather tenuous) workaround I've implemented is to check the ActiveForm against the first form in the Forms collection.