BeforeRowColChange, AfterRowColChange, RowColChange

The grid events, BeforeRowColChange and AfterRowColChange, occur when their names say—before changing row or column and after changing row or column. They give you the opportunity to prevent the change or to take some action because of it. VFP 7 added the very welcome RowColChange property, which helps us figure out whether the row, column, or both changed.

Usage

PROCEDURE BeforeRowColChange | AfterRowColChange
LPARAMETERS nColIndex
 
nChangeValue = grdGrid.RowColChange

Parameter	Value	Meaning
nColIndex	Column Number	In BeforeRowColChange, the number of the column you're leaving. In AfterRowColChange, the number of the column you're entering.
nChangeValue	0 (Default)	Indicates that neither the row nor the column changed. Reset to 0 on grid refresh.
	1	Indicates that just the row changed.
	2	Indicates that just the column changed.
	3	Indicates that both the row and the column changed.

In BeforeRowColChange, nColIndex is the number of the column you're leaving. In AfterRowColChange, it's the number of the column you've entered. Since these events fire on both row and column changes, we're baffled as to why there's a column parameter but no row parameter. Especially since you can get the same information from the grid's ActiveColumn property. Now, if they passed the reverse—the column you're headed for in BeforeRowColChange and the one you just left in AfterRowColChange—that would be handy. Of course, the same information would be useful for rows, too.Fortunately, VFP 7 added the RowColChange property to help us out here. RowColChange contains a number describing what changed, whether it was the row, column, both, or neither. It defaults to zero when the grid is initialized, and after a grid refresh. No longer do you need to track separate properties to track what row was active in the BeforeRowColChange and AfterRowColChange events. However, this still doesn't tell us which rows are involved.You can prevent changing cells by using NODEFAULT in BeforeRowColChange. Putting NODEFAULT in AfterRowColChange appears to have no effect at all. The docs indicate that BeforeRowColChange fires before the Valid of the control you're leaving and AfterRowColChange fires after the When of the control you're entering. Both are correct, but what they don't tell you is what happens if one of those controls returns .F. Fortunately, both behaviors are reasonably sensible. Returning .F. from the Valid leaves you in the same row and column you were in—AfterRowColChange doesn't fire. Returning .F. from the When sends FoxPro scurrying for a column that will accept the focus, if you got there with a keystroke. If you clicked into the cell that won't accept focus, you get a sort of false focus. The focus rectangle is there, but you can't type anything in. In either case, AfterRowColChange does fire for the cell that ends up with focus.BeforeRowColChange fires when focus leaves the grid, and AfterRowColChange fires when the grid gets focus.

Example

PROCEDURE BeforeRowColChange
LPARAMETERS nColIndex
 
* Decide whether to allow the change.
* This is a silly example designed to drive users nuts
* when the column changes.
IF This.RowColumnChange >= 2
   NODEFAULT
ENDIF
 
RETURN