>Hi George,
>
>Yes, I have noticed this. When focus is on the main VFP window, _SCREEN is actually referencing itself so this makes sense. However, when a child form is active (on top of a top-level form), _SCREEN.ActiveForm should return the object reference to the top-level form if it recieves focus with the child form(s) still present - this only occurs after the child form(s) are destoyed.
>
>It seems as if VFP confuses the top-level form with _SCREEN in the case where another modeless form is open (and yes, .ShowWindow = 1).
>
>The way I look at it, I have two choices:
>
>[1] Use top-level forms as an application workspace only with no contained controls.
>
>[2] Place code in the .Activate event of my form base class which sets a property in my application object to the active form's reference.
>
>Actually, I have already implimented the second approach. Since my app object maintains it's own forms collection, this addition virtually eliminates any need for my framework to ever use _SCREEN for anything.
>
>The question still remains: Is this a bug?
>
Hi Jeff,

I'd say no, and I'll explain why. When you create a top-level-form, the form is not a child of the _SCREEN. If you go into a tool like Spy++, and look at the window hierarchy, you'll see that a top-level form is shown as a completely separate entry. The windows are shown in treeview fashion, and the _SCREEN and top level form are on complete separate braches. In an application where the _SCREEN is use and the forms appear inside, you'll note that the forms will appear as children of the _SCREEN. This is the reason that I think that _SCREEN isn't reliable. Whether or not the same applies to the _VFP system variables, I don't know. But it is a place I'd check, even though my guess would be that it does.