>George,
>
>Thanks for the reply. I can do that too as well as walking the controls tree. However, I really don't want to force fellow VFPers to have to do that with my controls.
>
>A very funny caveat to this problem is that when my control is running on the form I can do:
>
>_SCREEN.ACTIVEFORM.ADDOBJECT('txt','textbox')
>
>Presto! A VFP Textbox is sitting inside my ActiveX control and when I move the ActiveX control, the Textbox moves with the control.
>
>That's pretty Cool!
>
>I've had so many problems with DBI Tech's ctDays control that I'm rewriting an Outlook Calendar control clone to use.
>
>The problems with DBI are:
>1. If you launch a VFP menu the control is still active and you can highlight it and add appointments that are no longer under your programatic control because the VFP menu is still in a wait state.
>2. The Click event doesn't always fire on the control after so many clicks. You have to click out of the control to some VFP area and then back.
>3. When highlighting Time Slots and then typing it doesn't alwasys fire the event to call the VFP code and then another erroneous appt is created.
>
>What a Pain!
>
>So if I'm building this control I want it to act as proper and dignified as possible.
>
>I'm going to add some more message handling into the control to see what else may be happening if possible. However, I still think it is in how the Window is defined. I've been also trudging through MFC documentation as well to see what Windows Styles and Class Styles they might be putting on that may be causing the problem.
>
>Maybe Mike Stewart or another MS Guru can come to our aid!


Maybe so. I'm not exactly sure what the root cause of the problem is either or if it's something that's "fixable". Admittedly, I haven't checked this with VFP 7.0...yet.< g >