>>Just curious if anyone else noticed similar behavior...
>>
>>In VFP 7 SP1, when setting the _SCREEN.AutoCenter = .T. while VFP/_SCREEN is maximized, the IDE, app, etc. partially jumps off of the screen, out-of-bounds and needs to be reset... (behavior can be duplicated from the command window)
>>
>>

>>*-- if VFP is not maximized already
>>_SCREEN.WindowState = 2
>>
>>*-- The following caused VFP to go out-of-bounds
>>_SCREEN.AutoCenter = .T.
>>
>>*-- reset to maximized
>>_SCREEN.WindowState = 2
>>
>>

>>
>>
>>VFP 6 SP5 does not do this. Very minor, but definitely annoying when done during the startup of an application...
>>
>>
>>Just wanted to know if anyone else sees this before submitting it as a bug...
>>
>>
>Brian,
>
>I see it, and I think I know why. _SCREEN refers now to the VFP desktop. What setting AutoCenter to .T. does is center the desktop. The frame is referenced by the _VFP object. You'll note that _SCREEN.hWnd does not equal _VFP.hWnd.


Hummm...

I think there is still a little problem though. Since _VFP does not have an AutoCenter property, you can't really center the application relative to Windows by simply setting the property. Notice that if you resize the VFP IDE and issue _SCREEN.AutoCenter = .T., even the resulting positioning of the desktop is higher than expected. Depending on where the IDE is before the AutoCenter is set also seems to affect where it's moved to.

Maybe I'm being picking, but Murphy's Law would lead me to believe that it could cause a problem at run-time...



- Brian