>>>>>Hi,
>>>>>
>>>>>As I go through my program, I see many places where I convert a string to date, using CTOD(), hard-coded with MM/DD/YYYY. But if the date is (for example), British ("DD/MM/YYYY") it won't work.
>>>>>
>>>>>How do you suggest I change all places that use CTOD() from hard-coded use of American date system to another?
>>>>>
>>>>>TIA
>>>>
>>>>If I had to do this task, I would write a program to scan through every PRG, VCX, SCX, FRX, wherever there was code, and identify all of the expressions with CTOD() and replace them with my_ctod(), and then add FUNCTION my_ctod to my utility.prg or main.prg, whatever is in the SET PROCEDURE TO path.
>>>>
>>>>The my_ctod() function would take the incoming form in the MM/DD/YYYY and you could translate it on-the-fly and return the value. Something like this (untested, off the top of my head):
>>>>
>>>>

* Note:  tcDate is MM/DD/YYYY
>>>>FUNCTION my_ctod
>>>>LPARAMETERS tcDate
>>>>LOCAL lnMm, lnDd, lnYyyy
>>>>
>>>>    lnMm = INT(VAL(GETWORDNUM(tcDate, 1, "/")))
>>>>    lnDd = INT(VAL(GETWORDNUM(tcDate, 2, "/")))
>>>>    lnYyyy = INT(VAL(GETWORDNUM(tcDate, 3, "/")))
>>>>
>>>>    * Compute date in a standard form
>>>>    RETURN DATE(lnYyyy + IIF(lnYyyy < 100, INT(YEAR(DATE()) / 1000) * 1000, 0), lnMm, lnDd)

>>>>
>>>>Something like that.
>>>
>>>Instead of adding this function to a procedure file, I would create a separate file and call it my_ctod.prg. I have stopped using procedure files many years ago, much easier with separate files.
>>
>>I was planning to convert some functions to PRG's, but how do you deal with the return value?
>
>No problem. A prg can return values, even objects, just like any other functions. Try for instance this code:
>
>

Lparameters tcFirst, tcLast
>Local loX As [empty]
>m.loX = Createobject([empty])
>AddProperty(m.loX, [FirstName], m.tcFirst)
>AddProperty(m.loX, [LastName], m.tcLast)
>Return m.loX

Strange, I thought at one point I tried it and it caused issues, then I did not give it more thought.