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.

WBORDER(), WCOLS(), WFONT(), WLCOL(), WLROW(), WROWS(), WTITLE()

One may know the world without going out of doors.
One may see the Way of Heaven without looking through the windows.
The further one goes, the less one knows.
—Lao-tzu

This group of functions tells you about the position and appearance of a window. Using them, you can retrieve almost enough information to re-create the window. Of course, it would be nice if you could retrieve all the information you need.

All of these functions work on the active window unless you pass the name of another window. If no window is active and you don’t name a window, the functions return information for the main FoxPro window. All work on both built-in and user-defined windows, as well as toolbars.

For forms and the main FoxPro window, much of the information returned by these functions can also be found using an assortment of form-level properties. That’s a good thing, since working with forms is almost always a better choice than defining windows by hand. Even better, when you work with form properties, you get to measure things in points rather than a unit that changes with the font.

Usage

lHasBorder = WBORDER( [ cWindow ] )

WBORDER() returns .T. if the specified window has a border and .F. if it doesn’t. The only way a window can have no border is if it was defined with the NONE clause. All system windows have borders.

There’s no way to find out what kind of a border a window has—only whether or not it has one. This is one reason you can’t gather enough information to re-create a window. (The other big problem is that there is no way to determine whether the window was defined with the keywords CLOSE, ZOOM, MINIMIZE, and so forth.)

Example

? WBORDER("command")  && Returns .T.
DEFINE WINDOW Test FROM 0,0 TO 10,60 NONE
? WBORDER("test")     && Returns .F.

Usage

nNumberOfColumns = WCOLS( [ cWindow ] )
nNumberOfRows = WROWS( [ cWindow ] )

WCOLS() and WROWS() tell you the size of the window, returning the number of rows and columns, respectively. The size returned is relative to the font used to define the window (see WFONT(), below) and represents the amount of space inside the border.

Example

DEFINE WINDOW test FROM 0,0 TO 10,10 FONT "Arial",10
? WROWS("test") && Return values depending on the Screen font
? WCOLS("test")

Usage

uReturnValue = WFONT( nAttribute [, cWindow ] )

Parameter

Value

Meaning

nAttribute

 

1

Return the name of the font for the specified window.

2

Return the font size for the specified window.

3

Return the font style for the specified window.

cWindow

Character

The window for which to return font information.

Omitted

Return information for the active window. If no window is active, return font information for the main FoxPro window.

WFONT() tells you about the font specified for the window. With three calls to WFONT(), you can find out everything there is to know about the font. Passing 3 for nAttribute returns one or more style codes, as shown in the following table.

Style Code

Meaning

B

Bold

I

Italic

N

Normal—none of the other options

O

Outline

Q

Opaque

S

Shadow

-

Strikeout

T

Transparent

U

Underline

Example

DEFINE WINDOW test FROM 0,0 to 10,40 ;
        FONT "WingDings",12 STYLE "BI"
? WFONT(1, "test")  && Returns "wingdings"
? WFONT(2, "test")  && Returns 12
? WFONT(3, "test")  && Returns "BI"

Usage

nLeftCol = WLCOL( [ cWindow ] )
nTopRow = WLROW( [ cWindow ] )

This pair of functions tells you where it’s at—the specified window, that is. They return the column and row, respectively, of the upper left corner of the window. This is the information you’d need for the FROM or AT clause of a DEFINE WINDOW command.

The name WLCOL() is nice and logical—you can read it as “Window Left Column.” But WLROW() is absurd—what’s “Window Left Row?” Technically, it should be WTROW() for “Window Top Row.” However, we can see the appeal of a matching set here.

The values returned by these functions depend on the font of the window that contains the window you’re asking about. Often, that’ll be the main FoxPro window. If you change the font of a window, the relative coordinates of windows in that window change.

Example

DEFINE WINDOW test FROM 10,10 TO 20,40
? WLCOL("test")  && Returns 10
? WLROW("test")  && Returns 10
MODIFY WINDOW screen FONT "arial",8
? WLCOL("test")  && Return values depending on
? WLROW("test")  && the original font for the screen

Usage

cWindowTitle = WTITLE( [ cWindow ] )

WTITLE() tells you the defined title of a window. For system windows, the title and the name are the same. For example, both the title and the name of the standard toolbar are “STANDARD”. For a user-defined window, the title is specified by the TITLE clause of DEFINE WINDOW or MODIFY WINDOW. If no TITLE clause is included, the window has no title.

Things are more complicated for a Browse window. This has been a source of confusion in FoxPro for years, since some commands require you to refer to a window by name, not title. If you issue BROWSE without a WINDOW or TITLE clause, both the name and the title of the Browse window are the alias of the table being browsed. If a TITLE clause is included in BROWSE, the window title is that specified string, but the window name is the first word of the title (from the first non-blank up to the first punctuation mark). For example, if you issue:

USE Employee
BROWSE TITLE "My Employees"

the window title is “My Employees”, but the window name is “My”. To move this Browse, you’d issue something like:

MOVE WINDOW my BY 5,5

If you issue BROWSE with a WINDOW clause and no TITLE clause, and the specified window has a title, the Browse window inherits that title. As before, the portion up to the first blank becomes the window name. Of course, we don’t generally have to worry about the naming of Browse windows any more, since we don’t use them in our applications—only to examine data when we’re developing.

Designer or editing windows draw their titles from the object being edited. For some, like MODIFY COMMAND and MODIFY FILE, the title is just the name of the file being edited. For others, like reports and forms, the title includes the name of the tool in use. If the word “Designer” appears in the name of the tool, the tool name is at the beginning of the window title. Usually, the name of the object being edited is part of the title, too; for example, “Report Designer - Report2”. In all these cases, though, the window name is the first word in the title.

To confuse matters more, the list on the Window pad shows window titles for system windows, but window names for user-defined windows. This is just plain confusing.

WTITLE() returns all caps for some windows, but certain system window titles are returned in mixed case. Titles defined with a TITLE clause are returned as they were specified. (That's a good thing, not a bug.) For this reason, it's a good idea to apply UPPER() or LOWER() to the results of WTITLE() and compare to all uppercase or lowercase strings.

Example

DEFINE WINDOW test FROM 0,0 TO 10,20 TITLE "My Test Window"
? WTITLE("test")    && Returns "My Test Window"
? WTITLE("command") && Returns "Command"

See Also

BorderStyle, Caption, Define Window, FontBold, FontItalic, FontName, FontOutline, FontShadow, FontSize, FontStrikethru, FontUnderline, Height, Left, Modify Window, Top, WExist(), Width, WMaximum(), WMinimum(), WOnTop(), WOutput(), WVisible(), Zoom Window