I use a lot of custom functions but there is one that I always include in every file. I have been using it for so long that I expect it to be in new files that don't have any custom functions. I think that I should donate it to Claris and ask them to include it in the next version update.
The function is really simple. It checks to see whether the current layout context is the one you want it to be. You pass it a field reference, and it returns true if the field occurs in the current layout table. I've talked about it a while ago, so you can copy it from that thread into your own solutions if you like.
I wonder what custom functions you've got that you think should be a FileMaker built-in?
the first thing coming to my mind is a number-to-text function with all the features you would expect and that already can be used when tweaking it for the interface in the inspector
That sounds great, string formatting in text objects is tedious.
positionValue by Josh Ormond. Nearly no app where I don’t use it!
And even more important: Regular expressions!
That's a great method. Definitely worth having as a CF.
I first thought I had a complex answer, then realized I have a simple answer.
I have many essential custom functions. The function that reduces my sweat the most these days is a 135-line monster that validates data. I give it a JSON structure that contains the data to validate and a JSON structure that contains the validation specification. It indicates whether the data conforms to the specification and, if not, the reason of the first failed validation.
Data, here, doesn't just mean JSON values. Both keys and values are validated.
I find myself routinely wishing that there were a FMP native version of Bruce Robertson's "AntiFilterValues" function.
Yes! JSON validation is so important. Does the JSONGetElementType function match any of that functionality?
No! My custom function doesn't validate the correctness of JSON structures. It validates the keys and the values within the JSON function against a specification. Key validation is limited to the existence of a key or not within a JSON structure. Value validation can check for any of the following: integer; non-empty; min length; max length; min value; max value; member of list; member of value list; negative; non list; non negative; positive.
Sounds like a fantastic function to have in one's toolkit.
Bruce's function is great. It does what I expect filters to do - which is to remove things.
I have one that takes a list array or JSON and makes it into Google Maps HTML. I think we all have various Date/Timestamp ones for conversions. I also have a History one that tracks record changes in a JSON format. I have one that formats currency into properly formatted text string or even spells out the wording of the currency amount. And I have one that gathers all of the stored values in a record and makes them into a JSON variable (useful when changing context to retain previous record data). Most of these are in the various FileMaker templates I share for free at https://tms.us/FM
All of those sound great. I'm going to have to check them out. And thanks for sharing.
I rarely create custom functions. More often, I will modify existing ones or combine some together.
One such alteration combines a custom function from @steve_ssh and another one from Kevin Frank to merge 2 JSON objects (not a shallow merge where only the first level get merged, but rather merging all the keys).
It also sounds to me like appending to a JSON array should be something the platform offers natively.
I'm sure we all lost some sleep over trying to establish the type of a given piece of data (is it a number, is it some text, is it a date, ...). It would be so much better if Claris was surfacing data types we can read for things we are handling.
Finally, there is a number of functions (specially get functions) I hope would get renamed for readability reasons. A bunch of them following a "object.attribute (optional param)" pattern where something like
Window.Width (optionalWindowName) would replace get(WindowWith), target the current window by default, but let us target another window if specified.
That's it, I think. So, I guess I cheated by not answering your original question directly, I hope can still inspire people. I am curious to see what others will mention.
I love custom functions, that make FileMaker Code more human readable, for example:
IsWindows ➔ get(systemplatform)=-2
IsMac ➔ get(systemPlatform) = 1
IsClient ➔ PatternCount (get(FilePath); "fmnet") =1
IsRuntime ➔ PatternCount ( Get ( ProgramVersion ) ; "Runtime" ) =1
Absolutely indispensable are 2 CFs (GFN and GTN) that get
a.) the name of a field without the relationship,
b.) the name of a field's table
so I can use it in SQL Statements in order to not break the code when the field gets renamed in the future.
I use custom functions a lot.
Sometimes they are quite simple but they make calculations more readable and easier to understand afterwards.
For example to work with value lists:
fValueAddBottom ( ValueList ; value )
fValueAddTop ( ValueList ; value )
fValueIndex ( ValueList ; value ) gives the index in the list of a certain value (not partially)
fValueInList ( ValueList ; value ) gives True when the value is found in the list (not partially)
fValueRemove ( ValueList ; value )
fValueListRemove ( ValueList ; ListToRemove ) removes a list of values from another list
fValueToggle ( ValueList ; Value) will remove a value if it already exists, or add it if it does not yet exist in the list
But the custom function I use almost always is a custom function to transfer multiple named parameters to scripts
If the parameter string is for example "Art_ID==" & $Art_ID & "|Method==Copy|Save?==0"
fGetScriptParam ("Method") gives as a result "Copy"
The order of the parameters is not important and it is not necessary to send all parameters.
If a parameter does not exist, the result = "?"
That is very much true!
I also have fTableName and fFieldName and use them also to build SQL commands without having fear it breaks up when a field name has changed
Similar to @LucThomaere, I use a custom function to transfer parameters to script. The one I use creates a variable for each top-level key of a JSON structure. While awfully handy and in use in just about all my scripts with parameters, I chose the validation custom function instead as my top choice because it is used just about as often and saves me a lot more scripting time.