Michelle --

First of all, thanks to Evan for reminding us of Christof's article...I will re-read it soon (suggest that you do, too). It was vary well-done and thorough, as I recall.

I just put together a quick & dirty approach to retro-fitting some old 2.6 apps to emulate VFP's SET CENTURY TO xx ROLLOVER xx feature. This method was easy easy to implement, however I had to come up with it on very short notice, and there are a couple of "gotchas." Please examine it carefully...admittedly, it may not be the most desirable solution in all cases.

Implementation is easy:
1. Put ROLL_OVER() somewhere in your app where it will be globally visible.
2. If you put the following code in the date box's VALID snippet, the date will be converted for you:

m.dMyDate = ROLL_YEAR(m.dMyDate)

In this example, m.dMyDate is a MemVar that is bound to the date box.

The code for ROLL_YEAR is included below...if nothing else, it might at least give you some food for thought. Hope this helps.

Bill

*******************************************************************************
* If a 2-digit year is entered in a date box, consider century roll-over
* (like VFP does) when converting to 4-digit year.
*
* Technical notes:
* a. This function should be fired from the date box's VALID snippet.
* b. FoxPro does internal date checking AFTER the user tries to exit the
* date box, but BEFORE the date box's VALID snippet fires.
* c. 2-digit years entered as "00" thru "29" are changed to 2000 thru 2029
* by this function.
* d. 2-digit years "30" thru "99" become 1910 thru 1999...these years are
* assumed to be 20th century years (a standard assumption in this version
* of FoxPro).
* e. 4-digit year entries are left alone.
* f. Since FoxPro does its internal date check before the date box's VALID
* snippet fires, an entry of "02/29/00" is invalid because FoxPro assumes
* 02/29/1900 (invalid) instead of 02/29/2000. However, if the user
* enters "02/29/2000", FoxPro recognizes this to be a valid date. There
* is apparently no practical way to modify this behavior.
* g. This function detects the last key that was hit, in order to determine
* how the user attempted to exit the date box:
* If the last key hit was a digit (0 - 9, or ASCII 48 - 57), then
* Chances are good that the user entered a 4-digit year.
* This function will leave the 4-digit year alone.
* If the last key hit was NOT a digit, then
* The user probably entered a 2-digit year.
* This function will convert the year from 2 digits to 4 digits.
* This function works fine, unless the user mouse-clicks out of the box,
* there appears to be no way trap the mouse-click in FoxPro 2.6.
*
* Parameters:
* m.ldKeyDate: The contents of the date box.
* Returns:
* m.ldRetDate: The date that is returned to the calling module.
*******************************************************************************
FUNCTION ROLL_YEAR
PARAMETER m.ldKeyDate
PRIVATE m.ldRetDate, m.lnKeyYear, m.lnKeyMonth, m.lnKeyDay

m.ldRetDate = m.ldKeyDate && Default return date = date entered.
IF (LASTKEY() < 48 ;
OR LASTKEY() > 57) && Last key hit was NOT 0 - 9.
m.lnKeyYear = YEAR(m.ldKeyDate)
IF (m.lnKeyYear > 1899 AND m.lnKeyYear < 1930)
m.lnKeyMonth = MONTH(m.ldKeyDate)
m.lnKeyDay = DAY(m.ldKeyDate)
m.ldRetDate = CTOD( STR(m.lnKeyMonth) + '/' + ;
STR(m.lnKeyDay) + '/' + ;
STR(m.lnKeyYear + 100))
ENDIF
ENDIF
RETURN m.ldRetDate


>I am trying to make an old 2.6 app Y2K compliant. What I would like to do is have it recognize 00 and up as 2000+, but not put the century in. They have character based dates, and I'm afraid if it sticks the century in that it won't work. Is this possible?
>
>Thanks,
>
>Michelle