RangeHigh, RangeLow

These events take the place of the old Range clause of @ … GETs. For text boxes and spinners, they fire on the way out and ensure that the value is within the specified range. If not, focus stays on the current control.

Usage

PROCEDURE oObject.RangeHigh
[ LPARAMETERS nControlIndex ]
RETURN nRangeHigh

PROCEDURE oObject.RangeLow
[ LPARAMETERS nControlIndex ]
RETURN nRangeLow

As with other events, the parameter is relevant only if the object involved is a control array. Then, nControlIndex indicates which member of the array fired the event.

We were surprised as heck to find these as events, not properties, but then we thought about it. In FoxPro 2.x, the Range clause could actually call functions to compute the boundaries, so there is a history of involving code. The two Range events each fire, Low then High, when attempting to shift focus to another control. They fire before Valid and LostFocus, and both fire, even if the RangeLow event fails.

In any case, to have these events function like the old Range clause, just have each one return the appropriate boundary value. We don’t recommend this, though, because if the test fails, the error message is the same old default WAIT WINDOW with a message like “Range: 0 to 20.” Do your testing in the Valid clause (or the field-level rules) where you have more control over what happens next. For spinners, if you don’t need code to compute the boundaries, you can store the range in the two property pairs SpinnerLowValue and SpinnerHighValue, and KeyboardLowValue and KeyboardHighValue. That’ll do a good job of keeping the user from entering the wrong value.

If you do choose to use these events, ensure that your routines return a numeric value, or a nasty infinite loop can occur, with the stupid control insisting "Range: to .T." Ever tried to type a .T. into a spinner? It's not easy! Incidentally, these events are just as stupid if you reverse the High and Low values.

Help is incredibly misleading about the relationship of these events to combo and list boxes. It appears to be just bad documentation, though, not any bugs in the product.

In FoxPro 2.x, the “1st Element” and “# of Elements” conditions for lists and drop-downs were implemented through the Range clause. (Take a look at a generated SPR to see this.) When you convert a 2.x screen that contains procedures (rather than expressions) for those items, whatever you had there goes in the RangeLow and RangeHigh events. In that case, RangeLow and RangeHigh do fire on the way into the form.

Other than that situation, as far as we can tell, RangeHigh and RangeLow never fire for lists or combos. The code is there, but it never gets executed. It definitely doesn’t specify which item in the control is initially selected, as the Help says. Try DisplayValue for that.

Example

* This method might be used for a text box on a form where
* the lower bound is based on another value entered on the
* same form.
PROCEDURE txtGrade.RangeLow
RETURN ThisForm.nAge - 5

See Also

DisplayValue, KeyboardHighValue, KeyboardLowValue, LostFocus, SpinnerHighValue, SpinnerLowValue, Valid