Yesterday I updated my list of new FileMaker features for version 11. The list I maintain doesn’t include everything (like the new Quick Start Screen, or text highlighting), but includes all of the items that affect our ability to program in FileMaker. So things like new script steps or changes to calculations.
The reason for doing this yesterday was that I was building into BaseElements the ability to recognise which calculation functions and script steps came from which versions of FileMaker. Using this list you can then say that to open this file, you need to use at least a minimum of FMP version X. There is a little more to do in BaseElements though to make it comprehensive, like extra features within certain script steps or layout features like web viewers or filtered portals. However, the functions area is more technical and is built into the XSLT in BaseElements, so I wanted to get that coding done first.
But I stumbled across an interesting bug I’d never noticed before in the FileMaker DDR. To test the various functions, including the Get functions, I built a file with a single calculation that included every possible built in function. Then I ran the DDR for this file and had a look at the details. To understand how the DDR works, when you have a long calculation, FileMaker breaks it into chunks. There are chunks for Fields, Custom Functions, Functions and everything else is a “NoRef” chunk (in other words text).
All of the built in FileMaker functions were reported, correctly, as “FunctionRef” nodes. I had thought that the most likely answer for the collection of the “Get” functions, was that the Get part would be a FunctionRef and the rest would be NoRef. Because in reality, the parameter you pass to the Get function is just a reserved word and the actual function is called simply “Get”. I was hoping that it might distinguish the reserved words in some way so I could figure out which ones it used, but I wasn’t sure what it would do.
It turns out in FMP 10, and I presume earlier versions, FileMaker reports some of the parameters as “FunctionRef” chunks and ignores some of them, so they end up in the text along with the round brackets and any whitespace and also anything that follows the function. I wasn’t sure what the logic for this was, there didn’t seem to be any consistency to it. And even stranger it reported one Get reserved word as a Custom Function.
I was all set to report a bug to FMI when I realised I had generated the DDR with FMP 10 and realised I should run the same test with 11. Well in 11, every Get reserved word is reported as a FunctionRef, so I can accurately report on them in BaseElements. So no bug report is in order.
What this does mean is that there could also be other differences and inaccuracies with the DDR in older versions that are fixed in 11, and I’d suggest that if you’re running any tool like BaseElements where you utilise the DDR that you should run it from version 11, just to be sure.
I do have a big feature request for the DDR though : That it broke the calculation into more discreet chunks. For example, plugin functions are reported as “FunctionRef” along side every built in function, it would be great to have a “PluginRef” type by itself. Comments and quoted text aren’t put into anything separate, it would be handy to have them put into a “TextRef” or CommentRef section. And technically the Get function types aren’t really functions, they’re reserved words, so a “ReservedWordRef” would be nice. Maybe in v12 🙂