problem with eom()

[Bruce Easton]

On 10/29/14, 10:40 AM, Kenneth Brody wrote:
> On 10/28/2014 11:08 PM, Bruce Easton wrote:
>> Testing under both Linux 5.7.4.07 and 5.0.14 shows the behavior and
>> requirement for the eom() function that Ken specifies. However, IMHO,
>> considering the history of differing requirements for functions over the
>> years regarding expressions versus fields, it not very helpful that 
>> both the
>> online manual and the screen help for eom() describe the parameter 
>> syntax
>> requirement as "date_expr" or "date expression".  I'm sure clerk is more
>> efficient with such strictness for functions, but the documentation 
>> should
>> be clearer.  And maybe for at least the screen help, it now is. An early
>> Windows filepro 5.7 still references "expression", but for the screen 
>> help
>> for the 5.7.4.07, it has been updated.  In the new screen help for 
>> the date
>> functions the parameters are referenced as "d" or "dd", and although 
>> I don't
>> see a specific reference that the parameter be a cast field of some 
>> sort,
>> there are examples now that conform to such a requirement.
> [...]
>
> 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.  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)

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

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).

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.