_Screen

This system variable makes it easy to manipulate the main Visual FoxPro window. It contains an object reference to the window that you can use to manipulate the window’s properties.

Usage

_SCREEN.Property = uValue
uValue = _SCREEN.Property
_SCREEN.Method()

The screen object is a little strange. It contains some properties that apply to forms (like Controls and ControlCount) and others that apply to formsets (like Forms, FormCount and ActiveForm). It doesn’t respond to any events, but it does have a small set of methods. The SaveAsClass method lets you create a visual class with the same characteristics as the window. However, it loses the formset properties en route and becomes a form-based class.

Some of the things you can do with _SCREEN, you can also do with MODIFY WINDOW. But it’s much more OOP-y to change properties using _SCREEN, and far more (though not all) of them are available. However, after you’ve made a whole lot of changes, it’s hard to remember how you found things. No matter how you made the changes, you can restore the main window to just about the condition you found it in by issuing MODIFY WINDOW SCREEN with no arguments.

There are a few items that aren't restored by this—one that we know of is DrawWidth. Some items are restored in practice, but _SCREEN's properties are wrong. BackColor is one like that.

One of the most common uses we find for _SCREEN is getting access to the currently active form through the ActiveForm property. This property contains an object reference to the form that has focus. Since toolbars are never ActiveForm, they can use _SCREEN.ActiveForm to call methods of the current form. _SCREEN.ActiveForm is also handy in the debugger to figure out what’s going on.

Don’t confuse _SCREEN with _VFP. That variable gives you access to the VFP Application Object, an Automation server with a whole bunch of PEMs of its own. While we primarily used _SCREEN as the “top” object in VFP 3.0 _SCREEN-based systems, with the introduction of top-level forms and Automation servers, we’re more likely to use the Application Object.

Beginning with VFP 7, the distinction between _SCREEN and _VFP becomes even larger. In older versions, the two objects shared those properties that describe the physical location of VFP on the monitor screen: Left, Top, Height and Width. Now, each has its own values for those items. _VFP’s properties describe the entire space occupied by VFP; _SCREEN’s properties describe the inside client area, omitting the area occupied by such things as the title bar, menu, status bar, and any docked toolbars. Having both sets of information available makes it easier to perform tasks that require precise positioning of forms or other objects. (Interestingly, when VFP is maximized, _VFP.Height and _VFP.Width are a few pixels larger than the available screen resolution. Our take is that maximizing puts the application’s borders just off-screen.)

_SCREEN gained several other properties in VFP 7. hWnd provides a window handle to VFP’s client area that makes using a number of Windows API functions easier. _VFP also has the hWnd property; as with the positional properties, it reflects the main VFP window.

_SCREEN also has the ShowInTaskBar property, but it’s read-only here, making it pretty much useless.

Example

* Personalize the screen
_SCREEN.Caption = "Hacker's Visual FoxPro"
_SCREEN.BackColor = RGB(0,0,255)
_SCREEN.ForeColor = RGB(255,255,255)
* or:
MODIFY WINDOW SCREEN TITLE " Hacker's Visual FoxPro" COLOR W+/B

* Call a method of the active form without knowing what form
* is in charge
_SCREEN.ActiveForm.SaveRecord()

See Also

ActiveForm, hWnd, Modify Window, SaveAsClass, ShowInTaskBar, _VFP