Steve, If you are using this date as part of a criteria for addressing a record set, I would use "Choose Distinct..." rather than a dialog. Then you won't have to worry about bogus entries, and, the user can only choose a date that actually exists in the data being queried.
If this is for data entry, I think I'd use a form and date field (even if it's the only field on the form), because you will spent more time/code verifying the date than it takes to create/maintain the form. Ben Petersen On 14 Jul 2003, at 10:46, J. Stephen Wills wrote: > Okay, suppose that I'm using a DIALOG to acquire user-input of a > date-string, MM/DD/CCYY. > Now, I want to convert this string into a DATE-type, fm its > DIALOG-implied type of TEXT. > As I don't see this type of conversion function "built in", > I was wondering what y'all might have to say to advise me. > > Here are some of my thoughts on the topic, assuming a TEXT value of > 08/17/1991 > f/var named vDateText (not a random value, our anniversary date, umm', > if I recall correctly) : > > - I could : > SET VAR vDateTextNew TEXT = ( CHAR(34) + .vDateText DATE + CHAR(34) ) > then > SET VAR vDateType DATE = &vDateTextNew > but, I'm having trouble getting that second double-quote to suffix > properly > (Yep', Bill, because you once asked, I'm still using DBL-Quotes, ) > (but let's chat about that later, unless it's of issue here ... ) > > - I also could create 3 INT's > SET VAR vIMON INT = (INT(SGET(.vCutoffDateTXT,2,1))) > SET VAR vIDAY INT = (INT(SGET(.vCutoffDateTXT,2,4))) > SET VAR vIYR4 INT = (INT(SGET(.vCutoffDateTXT,4,7))) > then > SET VAR vDateType = (RDATE(.vIMON, .vIDAY, vIYR4)) > > - I know that I could use a form w/a DATE-type variable, > or even a DATE field fm a DUMMY table, so I wouldn't have to fool > w/this, > but I've chosen not to do that, at least f/now. > > > DATE SETTINGS ARE : > > FORMAT MM/DD/YYYY > SEQUENCE MMDDYYYY > CENTURY 30 > DEFAULT 19 > > > TIA, > Steve in Memphis >
