>>>Does anybody Know if Foxpro for Windows 2.6 have problems with year 2000?, and where I can get fixes for this problem.
>>>
>>>Thanks
>>Yes, it does have problems.
>>If you have a user-entry field on a form, and you have a date field
>>for them to enter, and if they omit the century (i.e. they type in 12/15/01),
>>FoxPro assumes (always no mattter what you have setup in code) that the
>>century is 19. No matter what. So, you have to write a function which you
>>call that compares the year century entered to the actual system date century
>>and then give the user the option to choose the century (since it may be Jan 2000 and they might be entering data for 1999).
>>
>>MS was sued just over this. The girl that sued them was correct.
>>MS FoxPro programmers hosed up here, they certainly have a hard coded
>>century setup instead of getting the century from the system. They should
>>have lost that lawsuit but the judge declared it worked as documented.
>>I know because I had to write a function that did just that - and I easily
>>got the century from the current system date - foxpro has the ability to
>>get it - the MS programmer just had no vision.
>>
>>The programmer who coded that should hang his head in shame. I mean it.
>>I recall an old excellent programming book "Programming Proverbs" and there
>>was a phrase in that that I am paraphasing that went something like:
>>"If the programmer refuses to write good code, he should be taken out and
>>shot. If it is inconvenient to shoot him . . .".
>>
>>This flaw in FPW reminds me of that quote.
>
>
>Carl,
>
>I'll stand with you on this one. Granted, even if FPW 2.6 had the ability to be "smart enough" to just grab the current century for a year entered with 2 digits we would still have some more coding to do to make our applications Y2K compliant. VFP's implementation of rollover is an excellent step towards fixing y2k issues in foxpro. Granted, even with FPW 2.6 as it is we can make dates work with any century.
>
>That being said, I think you are exactly right that at some point, some programmer (and it was probably long before Microsoft owned FoxPro) had to make a decision for date handling and he decided to hard code a default of the 19th century. Looking back with 20/20 hindsight, that was definitely a mistake.
>
>I know that in the software we program, we try not to hard code assumptions that we know will become false at some point in the future. I'm sure that I'm not near as good a programmer as the guys who have written and maintained FoxPro and its predecessors, but it seems like somebody should have fixed that assumption long before Visual Foxpro came out. It sure would have saved my company, and an aweful lot of other Fox Programmers a lot of time with this Y2K thing. Just think, on February 29, 2000, you would actually be able to key in the current date!
>
>I know there is a lot of passionate defense for the fox platform here, and its definitely a platform that I love, but I've been using it long enough to know that they didn't do everything perfect.
>
>Of course, they probably made a lot fewer mistakes then I have in the software I've written with it, so maybe I've got no room to complain.
>
>All of this is of course, just my opinion.
>
>Paul R. Moon

Paul, your response brightens my year! It is true that VFP and FPW are truly
great products - I love them. However, too many people who use Microsoft
products have a myopic view of the world - and tools, and what to expect
of tools. It is too bad that Microsoft does not love VFP as we developers
do - for if they did, they would market it - which they do NOT!
Anyhow, thanks for your comment, there have been some comments from people
who I know of and respect that disagree with me totally - that is what makes
the world.
So, thanks again, sometimes when one is right, one must stand alone, today
I see that someone else can "see the light".
Thanks.
Carl R. Perkins