problem with eom()

[Kenneth Brody]

On 10/29/2014 12:18 PM, Bruce Easton wrote:
> On 10/29/14, 10:40 AM, Kenneth Brody wrote:
[...]
>> Point taken.  Note, however, that:
>>
>>     foobar(12) { "/01/" { foobar(13)
>>
>> is not a "date expression".  It's an expression that returns a simple
>> string which happens to "look like" a date.  And, in the specific example
>> in the OP, it could be either "MDYY/" or "DMYY/".  It's not possible, in
>> the general sense, for filePro to "know" what type of date you want it to
>> be interpreted as.
>>
>> [...]
> I did understand that point when you first mentioned it.  From a high level
> programming view though,  don't think it's unreasonable for one to guess
> that filepro might be keeping track of the edit of the ultimate target and
> that "expression" in this case could be something less restricted than it
> is.

Assuming, of course, that the result of EOM() is immediately stored in a 
field, such as:

     EndDate = EOM(something)

However, there is no guarantee that such a construct is in use.

>  I think sometimes examples serve better to avoid misunderstanding of
> general terms like "expression" (of whatever kind). I was getting ready to
> ask - what else can "date expression" be in this case besides a case
> field/dummy/long_var?   But I tested on 5.7.4.07, and discovered that although:
>
> eom(1{"/01/"{2)    'will always return the undesired results (same as if
> parameter was blank)

Parameter is an expression of type (some_length,*)

> eom(sd+"33")       'does actually work if sd is a valid date edit and the
> desired result is the last day of the month of the date that is 33 days
> after the date sd

If sd is a date field, then sd+"33" is a date as well.

> So unlike the old mid function which required that the first parameter be a
> field (and said so clearly in the help), and unlike the expression involved
> in today's mid function, the parameter of the eom function is "date
> expression" - if you want to call it that - where it must involve at a
> minimum, a field/dummy/long_var that is cast as a valid filepro date edit (a
> field typed by filepro as a date edit or a date calculation that would
> result in a field typed by filepro as a date edit).

You could say that "date expression" is any expression which results in a 
date value.  The apparently-too-terse help file is basically saying "the 
parameter must be a date", but doesn't go on to explain what happens if a 
non-date is passed.  (Just as dcabe.hlp used to not explain what happens if 
you pass SQRT a negative number.)

A better description might be:

The parameter is an expression.  If that expression is a date, then EOM() 
[and the other date-related functions] will use that date.  Otherwise, the 
current date is used.

> Unless I missed it in the new updated help for these functions, I don't see
> an example similar to 'eom(sd+"33")' detailing what else "d" or "dd" can be.

-- 
Kenneth Brody