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
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only