>I have a form that contains a Page Frame. Page1 contains another page frame. On page 3 of the second or internal page frame is DBI Techs List Box (Active X Control).
>
>If the user clicks on Page 1 of the form Page Frame and then Clicks on Page 3 of the internal Page Frame and then makes a menu choice where I programtically switch the form page frame to say page 2. The DBI Tech List box overlays controls on the newly shown form Page frame.
>
>If the user changes themselves to page 2 of the the form page frame I do not have the problem. Only when I do this programaticaly
>
>I have had other refresh problems that were different but was able to take care of those problems by doing a SETFOCUS() on the ActiveX Control. This did not work here. I tried setting the ZORDER(1) on the ActiveX Control prior to changing the form level page frame. This did not work.
>
>Looking for some suggestions. Thanks in advance

Ron, it must be me, but I myself always fight with ActiveX; IMO somehow somewhere it's not consistent with the VFP-environment. It always has to do with the problems you describe. In order to hide these anomalies I usually work with in fact unnecessary LockScreen's, Refreshes etc.;
Objects like these often don't respect things like the Height of a form (just grows over it) or get partly not repainted or ... all kind of things which are sometimes hard to get around.
The general idea is to think on (IMO !!) the fact that the ActiveX object not really is "within" the other object, though you defined it like that. Whether this is true or not I'm not sure, but it feels like that. Once you think this is the case, you can can get around these anomalies (i.e. use LockScreen = .T. at the proper place, the Refreshed idem, and LockScreen = .F. again). Sometimes it even needs Visible = .F. and .T. again to Refresh (with LockScreen .T.).

You'll get around this one ...
HTH, kind regards, ...

So far this millenium feels just like the last. ...
... But the last wrote double-n {g}