problem with eom()

[Kenneth Brody]

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.

If the help files don't explicitly state that passing a "non-date 
expression" will return the end of the current month, then it should be updated.

-- 
Kenneth Brody