Logo

Hacker’s Guide to Visual FoxPro
An irreverent look at how Visual FoxPro really works. Tells you the inside scoop on every command, function, property, event and method of Visual FoxPro.

DEFINE WINDOW, RELEASE WINDOWS, ACTIVATE WINDOW, DEACTIVATE WINDOW, HIDE WINDOW, SHOW WINDOW, MOVE WINDOW, MODIFY WINDOW

This group of commands lets you work with windows the Xbase way. Many of their capabilities have been superseded by use of properties and methods, though some still require these commands.

Usage

DEFINE WINDOW WindowName
        FROM nTop, nLeft TO nBottom, nRight
        | AT nTop, nLeft SIZE nHeight, nWidth
        [ IN [ WINDOW ] ContainerWindow | IN SCREEN
          | IN DESKTOP | IN MACDESKTOP ]
        [ NAME ObjectName ]
        [ FONT cFontName [, nFontSize ] ] [ STYLE cFontStyle ]
        [ TITLE cWindowTitle ] [ FOOTER cWindowFooter ]
        [ HALFHEIGHT ]
        [ DOUBLE | PANEL | SYSTEM | NONE ]
        [ CLOSE | NOCLOSE ] [ GROW | NOGROW ]
        [ FLOAT | NOFLOAT ] [ MDI | NOMDI ]
        [ MINIMIZE | NOMINIMIZE ] [ ZOOM | NOZOOM ]
        [ SHADOW | NOSHADOW ]
        [ FILL cFillChar | FILL FILE FillFileName ]
        [ ICON FILE IconFileName ]
        [ COLOR SCHEME nColorScheme | COLOR PAIR ColorPairs ]

Out of all that mess, only one clause is new in Visual FoxPro—the NAME clause. It’s the key to making user-defined windows easy to work with. NAME lets you turn the window into a form object. Once you do that, you can manipulate its properties directly and avoid working with the other commands in this group. There are properties corresponding to almost all the clauses above that actually work. (A fair number of the clauses are included only for backward compatibility and are ignored in Visual FoxPro.) Get in the habit of creating forms and manipulating their properties that way, and your code will be far easier to read and maintain than trying to decipher this behemoth of a command.

You have two options for specifying the initial size of a window. The AT - SIZE option is more in tune with the Visual FoxPro way, since its parameters map directly onto the Top, Left, Height and Width properties.

The table below shows the mapping of DEFINE WINDOW clauses to form properties.

Clause

Property

Meaning

FROM - TO, AT - SIZE

Top, Left, Height, Width

The size of the window.

FONT

FontName, FontSize

The font and size for the window.

STYLE

FontBold, FontItalic, FontOutline, FontShadow, FontStrikethru, FontUnderline

Font attributes for the window.

TITLE

Caption

The caption that appears in the window's title bar.

HALFHEIGHT

HalfHeightCaption

Should the window have a half-height title bar?

DOUBLE, PANEL, SYSTEM, NONE

BorderStyle, BorderWidth

The type and size of the window border.

CLOSE, NOCLOSE

Closable

Can the window be closed by double-clicking in the Close box?

GROW, NOGROW

BorderStyle

Can the window be resized?

FLOAT, NOFLOAT

Movable

Can the window be moved?

MDI, NOMDI

MDIForm

Does the window behave like an MDI window?

MINIMIZE, NOMINIMIZE

MinButton

Can the user minimize the window?

ZOOM, NOZOOM

MaxButton

Can the user maximize the window?

FILL FILE

Picture

The bitmap used as wallpaper.

ICON FILE

Icon

The icon to use when the window is minimized.

COLOR SCHEME, COLOR

BackColor, ForeColor

The colors for the window.

There are a few clauses that work but don’t have exact parallels among the form’s properties. The various IN clauses that specify the container of a particular window can’t be duplicated in the object model.

In addition, ForeColor and BackColor don’t provide the same degree of control offered by the COLOR SCHEME and COLOR clauses.

Usage

RELEASE WINDOWS WindowList | SCREEN

This command undefines one or more windows. If you use the NAME clause when you define the window, you can do this by calling the window’s Release Method instead.

RELEASE WINDOWS also lets you deactivate system windows and toolbars.

Watch out for the SCREEN clause—RELEASE WINDOW SCREEN attempts to shut down VFP, even if it's issued in a top-level form.

Usage

ACTIVATE WINDOW WindowNameList | ALL | SCREEN
        [ IN [ WINDOW ] ContainerWindow | IN SCREEN
          | IN MACDESKTOP ]
        [ BOTTOM | TOP | SAME ]
        [ NOSHOW ]
DEACTIVATE WINDOW WindowNameList | ALL
SHOW | HIDE WINDOW WindowNameList | ALL | SCREEN
        [ IN [ WINDOW ] ContainerWindow | IN SCREEN
          | IN MACDESKTOP ]
        [ BOTTOM | TOP | SAME ]
        [ SAVE ] [ REFRESH ]

These commands turn windows on and off. A window must already be defined to be ACTIVATEd or SHOWn and DEACTIVATEing or HIDEing a window doesn’t undefine it. The difference between ACTIVATE and SHOW and between DEACTIVATE and HIDE is subtle. SHOWing a window makes it visible, while ACTIVATEing a window both makes it visible (unless you specify the NOSHOW clause) and gives it the focus. HIDEing a window makes it invisible, while DEACTIVATEing a window both makes it invisible and clears out its contents.

When you work with window objects (via DEFINE WINDOW’s NAME clause), these distinctions are handled differently. The Show method activates a window and gives it focus, like ACTIVATE WINDOW. But the Hide method behaves like HIDE WINDOW, making the window invisible without clearing it. If the window doesn’t contain any objects, the Cls method clears it. However, if you use AddObject to put objects in the window, you have to RemoveObject each object to clear it out.

The Show method can’t handle the various IN clauses or the positioning clauses BOTTOM, TOP and SAME. Show also doesn’t offer an equivalent to ACTIVATE’s NOSHOW clause, which lets you activate a window without making it visible—you can SHOW WINDOW later. FoxPro 2.x’s GENSCRN uses NOSHOW in the screens it generates to keep users from seeing all the controls being drawn. (This is something of a non-issue because controls added with AddObject are invisible until you explicitly make them visible, and you don’t have to activate a form window to put controls in it.)

The SCREEN clause applies only to ACTIVATE WINDOW and SHOW WINDOW, and appears to be most relevant when you have windows that are defined IN DESKTOP. Then, the SCREEN clause lets you reactivate the main VFP window.

The REFRESH clause of SHOW WINDOW updates a Browse with the most recent data.

The SAVE clause of HIDE WINDOW and SHOW WINDOW is ignored—it’s a relic from FoxPro/DOS.

Usage

MOVE WINDOW WindowName
        TO nNewTop, nNewLeft | BY nRows, nCols | CENTER
MODIFY WINDOW WindowName | SCREEN
        [ FROM nTop, nLeft [ TO nBottom, nRight ]
           | AT nTop, nLeft [ SIZE nHeight, nWidth ] ]
        [ FONT cFontName [, nFontSize ] ] [ STYLE cFontStyle ]
        [ TITLE cWindowTitle ] [ HALFHEIGHT ]
        [ DOUBLE | PANEL | SYSTEM | NONE ]
        [ CLOSE | NOCLOSE ] [ GROW | NOGROW ]
        [ FLOAT | NOFLOAT ]
        [ MINIMIZE | NOMINIMIZE ] [ ZOOM | NOZOOM ]
        [ SHADOW | NOSHADOW ]
        [ FILL FILE FillFileName ]
        [ ICON FILE IconFileName ]
        [ COLOR SCHEME nColorScheme | COLOR PAIR ColorPairs ]

It’s when you get to these two commands that the ability to make a window into an object really shines. Instead of issuing the verb-oriented MOVE WINDOW or MODIFY WINDOW commands, we can simply tweak the properties of an object to get it to do what we want. The table above shows which properties to change for which clauses. (Use AutoCenter to get the effect of MOVE WINDOW CENTER.)

As in the other commands, the SCREEN clause addresses the main Visual FoxPro window (which you can also reference via the system variable _SCREEN). We do occasionally use MODIFY WINDOW SCREEN with no arguments to restore the defaults without having to remember what we’ve changed. One caveat—MODIFY WINDOW SCREEN clears the screen as well as resetting its properties.

Example

* Let's try doing things the old way and the OOP way
DEFINE WINDOW test FROM 5,5 TO 15,50 DOUBLE ;
   TITLE "Test Window" FLOAT GROW ZOOM MINIMIZE CLOSE
ACTIVATE WINDOW test
* now change some attributes
MODIFY WINDOW test NOFLOAT NOCLOSE TITLE "Whaddaya think?"
MOVE WINDOW test TO 10,8
RELEASE WINDOW Test

* Here's the OOP way
DEFINE WINDOW test FROM 5,5 TO 15,50 DOUBLE ;
   TITLE "Test Window" FLOAT GROW ZOOM MINIMIZE CLOSE ;
   NAME oTest
oTest.Show()
* now change some attributes
oTest.Movable = .F.
oTest.Closable = .F.
oTest.Caption = "Whaddaya Think?"
oTest.Top = 10
oTest.Left = 8
oTest.Release()

Although the second version takes more lines, we find it much easier to follow. In fact, we’ll only be using DEFINE WINDOW with its multitude of clauses when we can’t avoid it.

Beware: The two versions aren’t exactly identical. The measurement schemes used for the old way and the Xbase way are different. MOVE WINDOW measures in rows and columns, while Top and Left are measured in either foxels or pixels, depending on the window’s ScaleMode.

See Also

AutoCenter, BackColor, BorderStyle, BorderWidth, Caption, Clear Windows, Closable, ColorScheme, FontBold, FontItalic, FontName, FontOutline, FontShadow, FontSize, FontStrikethru, FontUnderline, ForeColor, Form, HalfHeightCaption, Height, Hide, Icon, Left, MaxButton, MDIForm, MinButton, Movable, Release, ScaleMode, _Screen, Show, Top, Visible, Width