POPUP() | Hackers Guide to Visual FoxPro 7.0

ErrorMessage, Message

Unlike Error, ErrorMessage shouldn't be part of anyone's error-handling strategy in new applications. Like Message, it's a backward-compatibility method included to make it possible to port FoxPro 2.x code to Visual FoxPro.

ErrorMessage fires when an object's Valid returns .F. If you return a string, it gets displayed in a WAIT WINDOW. Message is similar. It fires when you land on an object, and places the returned string in the Windows-style status bar (or at the bottom of the screen, if you're not using the status bar).

Usage

PROCEDURE oObject.ErrorMessage | oObject.Message [ LPARAMETERS nIndex ]

ErrorMessage and Message share a weird bug with When and Valid. When you define an ErrorMessage method or a Message method for a control array, it doesn't always fire when it should. For some types of controls, the class the control is based on must include a definition for the same method or FoxPro can't find the one for the control array. You don't have to actually put anything in the method, just define it. Very strange. Of course, it's also fairly irrelevant because we can't think of any reason to use control arrays.

ErrorMessage is the Visual FoxPro replacement for the ERROR clause of @ ... GET. You can actually put anything you want in the method, but whatever you return is displayed in a WAIT WINDOW (if NOTIFY is ON). A better choice is to present whatever message you need in the control's Valid (using WAIT WINDOW or MessageBox) and then return 0 from the Valid.

Message replaces the MESSAGE clause of @ ... GET. It works the same as ErrorMessage except the returned text appears in the status bar. StatusBarText does the same thing and isn't labeled "For Backward Compatibility."

Example

PROCEDURE spnMonth.ErrorMessage RETURN "Choose a month between 1 and 12"