Hi chris,

You're probably using SET DATE SHORT or SET DATE LONG. Those settings cannot handle dates before the year 1601 because of a windows limitation.

if you SET DATE to anything else it won't show this error. The worse part is that the error could not be captured properly: it is erroring on you READ EVENTS line.

There is a workarround I found that works reasonable well, but I did not test this in all circumstances. It involves messing arround with the Dateformat property of the textbox in the gotfocus and lostfocus event as even with SET DATE SHORT and SET DATE LONG entering dates will always be in a DMY, MDY OR YDM order (with numbers and seperators).

Walter,


>We're having a problem with the date handing in VFP 8. In VFP 8, if you have a bound text box with a date and you enter an invalid date and try to leave the field (12/01/203 for instance) VFP 8 immediately throws a "Date/datetime evaluated to an invalid value" error. In VFP 6 the bad date is written to the table, but does not display in the text box once the text box loses focus. But more importantly, you don't get an error.
>
>One odd thing is that the docs say that StrictDateEntry=1 (strict) will throw an error for invalid date, but the 0 setting (loose) will not. However, either setting will actually throw an error. The worst part is, the error is raised before Valid or LostFocus is called, so you can't test the date first.
>
>On top of that, VFP 6 behaved differently.
>
>This is causing problems since we use text boxes to edit date fields (both bound and unbound) and they will now cause errors if we update to VFP 8. Of course this can be worked around with an error handler, or translating dates to characters for editing.
>
>I was wondered if anyone else had come up against this? If so, is there a switch or something that might cause VFP 8 to behave like 6?
>
>Thanks,
>CHris