Nuanced data-type behavior change in FM Pro calculation engine, v.19.6.1

Hello,

As best as I can tell, there is a small change in behavior in the FileMaker Pro calculation engine which occurred between v.19.5 and 19.6.1. Please note that I have not tested to see of this change occurs across all FM Pro platforms -- I have only investigated this on MacOS (12.6.1).

Background:

Behavior that I have always observed and expected is that many/most functions and operations in the FM Pro calculation engine return values which have an associated data type that corresponds to the result type of operations.

For Example:

There are some operations which one intuitively expects to return a value of type Text, such as the result of functions such as Substitute, Left, Right, or concatenation with the & operator.

There are other functions/operations which one intuitively expects to return a value of type Number, such as the result of the function PatternCount, or Position, or the result of using the arithmetic operator +.

Change Between 19.6.1 and previous versions:

In versions prior to 19.6.1, the Trim function returns a value which retains the data-type of the input value.

In contrast, in v19.6.1, the Trim function seems to always return a value which has a data-type of Text.

It's a nuanced change, and for those of us who tend to explicitly cast values when there is any chance of uncertainty about the data-type, it is not likely to cause any issues. But, if you find yourself maintaining some code that makes assumptions about data-types, this is the sort of change that could result in code breaking with an update to v.19.6.1.

I experienced this today with a solution that suddenly stopped working properly because a value which, prior to 19.6.1, had been treated as a Date, started being treated as Text when the FMP client version was updated to 19.6.1. The solution was to patch the calculation that was making an assumption about a variable's data type. It took me some time to track down the cause of the issue, hence I figured I'd post a heads-up to my friends here at the Soup, in case it saves anyone else some detective work.

Some screenshots below attempt to illustrate. The screenshots show a comparison between v.18 and v.19.6.1. That said, I believe that the change actually happened between v.19.5.4 and 19.6.1.

Also, to reiterate, I have only focused in on this matter on a MacOS machine (though, given the nature of the issue, I suspect that this will be change be present across all supported platforms.

Hope this helps.

Behavior in v.19.6.1 of FileMaker Pro

Behavior prior to v.19.6.1 of FileMaker Pro

9 Likes

Interesting. I can confirm the change.

19.6

vs 19.5:

vs 14.0

Seems like in recent versions Claris rewrote a few functions with unnoticed behaviour changes.

6 Likes

This is certainly an important discovery for many.
Thank you @steve_ssh

1 Like

Interesting…

Claris should have documented the Trim function's behaviour change. That said, the help text for FileMaker 18 and 19 both say the Trim function returns text, so I would say this is Claris fixing the Trim function to behave as documented.

(See FileMaker 18's help doc here and FileMaker 19's doc here.)

4 Likes