Special Date Edit

[Kenneth Brody]

On 10/7/2015 5:00 PM, Richard D. Williams wrote:
> Ken,
>
> See my comments below.

Where else would they be?  :-)

> On 10/7/2015 9:28 AM, Kenneth Brody wrote:
>> On 10/7/2015 9:01 AM, Richard D. Williams via Filepro-list wrote:
>> [...]
>>> Have to fields for the data, one is a regular date edit (10, mdyy/)and the
>>> other simply require nn/nn/nnnn. (n could be a number or n could be a ?)
>>> Put a dummy field on the screen with the nn/nn/nnnn edit
>>> When the cursor leaves this field you must first look for any ?, this would
>>> tell you NOT to fill in the real date field and put this data into the other
>>> real field.
>>
>> Why look for "?"?  Why not just store it into your mm/dd/yyyy field? If
>> it's a valid date, you'll get a valid date field.  If not, you'll get a
>> blank date field.
> I think he wants to attempt to get all dates in the generally correct
> chronological order.
> So if a date is entered as 10/??/2010, at least this will be in
> chronological order as 10/00/2010.
> Or 10/07/???? will still be at the beginning. He can also see which part of
> the date is missing.

Yes, but why the extraneous step of checking for "?" before storing it into 
a "real date field"?

> If the date is blank they will all be at the beginning.
>>
>>> If there are no ? in the field, test it by using another dummy var while a
>>> real date edit and attempt some date math, i.e. ha(8,mdy/)=hb+"0", (hb is
>>> the dummy var on the screen)
[...]
>>> If you get 01/01/83 or no date at all you know there is an issue.
>>
>> When would you get "01/01/83"?
> If a text field like 13/43/2015 is place into a date field of hc(10,mdyy/).
> If you try to any math on that field, like hb(8,mdy/)=hc+"0", hb will be
> "01/01/83".

Yes, *if* hc were a blank date field.  The given code was not a date field.

[...]

-- 
Kenneth Brody