Could use some more info.
You can pass multi valued variables, then parse them out in the script.
9 times out of 10, I find that the list method is perfectly adequate to the job. There are exceptions and you mention one: cases where more than one parameter might be null. Cases where more than one might contain returns is another. I find these cases rare and thus stick with list when possible as it is both simple and self documenting
In cases where list won't do, FileMaker 16 offers the option of passing a JSON as the parameter with built in functions for both building and parsing data into/out of the JSON.
I have FMP16 Advanced, so I will take advantage of JSON parameters then (even though the writing portion looks a little extensive, the overall usage/ease of use is far easier- specially in areas where not all variables would be needed, such as opening a new window at a select size).
This is the current script that is going to need/use the JSON (once I figure it out better) and its accompanying custom function:
I did not want to have to constantly re-write WindowExists in calculations many times, so that is 1. But the Open Window would be useful if it had a script version of Custom Functions area (which there really should be).
Exactly what do you mean by
"script version of Custom Functions area"?
and what problems would that solve for you?
Filemaker sort of has this ability, but 'Custom Functions' lacks actual 'functions' and is instead just calculations (they always return some value, and cannot do any actual script steps like 'New Record'). Custom Functions also surpsingly lacks data specifics (such as "Age" must be a number).
Being able to place a true custom function (such as my OpenWindow script) the same as 'newrecord' and having the available parameter options popup like normal script steps do, would open up HUGE worlds in making FileMaker easier for general use and adds a giant amount of functionality WITH the ease of use (skipping the JSON step entirely and not being required to rewrite the considerably giant text for 2-4 parameters, for example).
FileMaker's terminology is more like that of Excel than of programming languages, so the use of the term "Custom Function" is meant to suggest a calculation operation rather than a subroutine - there are historical reasons for this based on the product's origins. FileMaker started with the intention of not requiring you to be a "programmer" to use it, so what you consider to be right and proper is not necessarily an opinion shared by the majority of the userbase.
Without wanting to speak for the product's designers, I think they had this spirit in mind when they designed the revamped calculation engine in v7 back in the early 2000's. By making the parameter (and variables) simply of type text they eliminated a number of potential errors that could prove confusing to users without a programming background, while still retaining enough flexibility for those with the technical ability to layer a more sophisticated process on top.
If you are looking to override the existing commands with your own process then I suggest you look into the Custom Menus functionality, which allows you to specify a script to be run by a given menu command. Although (in traditional FileMaker fashion) it's a fair amount of work and feels like a weird workaround to someone used to "industry-standard" programming languages, it will let you do what you need.
1 of 1 people found this helpful
If you want, my session at DevCon this year covered this topic. You might be interested in reviewing the session materials: ADV003 - Abstraction and Indirection in FileMaker - Mike Mitchell
1 of 1 people found this helpful
According to Clay Maeckel (the lead engineer at FileMaker), the reason all data are stored as text is to make it easier when people switch data types on existing fields. So yes, it was specifically designed to make it easier for folks without a programming background. That has always been a key value at FileMaker, and I don't expect it ever to change.
not being required to rewrite the considerably giant text for 2-4 parameters, for example).
I'm not sure I follow this part. If you use JSON to pass parameters around then you would just pass the ones you need. The receiving script can check for any and all key names in the JSON and will get the ones that are passed and empties for the ones that weren't. So you never have to construct JSON with empties for the parameters you don't want to pass.
Which makes JSON a nice alternative to other methods, which will typically require a value or null for every parameter.
So far... the PDF (of slides) and the example are great! I can' wait until they release the video.
The problem I have with having to use JSON and other methods (like lists) is that is OVER complicates the programming of the simple script's far beyond what "no programming experienced required" by suddenly dropping in mid-level difficulty of JSON programming (not always an easy thing) with some extensive calculations that are just over the top making things harder than they should be.
Making custom functions is easy, and it can get difficult yes. But having scripts that can be easily reusable (like my script for Open Window), would make things far easier. I believe this whole concept of "no programming experience required" has simplified things so much that certain important tasks (like reusable code) have been made too complicated to handle for the demographics of "no programming experience required" to handle and makes people stray away from the software. Some ease on this demographic of users should be put off to truly make things easier. I understand that parameters should be only in text- yes, that is perfect. But there could be some control, if this system was put in, to check if the text could truly convert to the needed type of information (taking out error checking from the user side, which is a LOAD of work for this demographic as it is, making things simple).
I come from a past experience in C/C++/C#/Java/Processing (made from Java), and LOVE how this software handles every piece of the graphical user interface for me in the background, but it lacks a load of useful piece for those who happen to not fall in the demographic of "no programming experience required" and want to design software with more use or more advanced features. I know I can use C/C++ to create plugins, but that is something I can find very little information on- not even a tutorial (And I find that C/C++ is not the best language in terms of easy to use, when compared to higher end C# and Java- mostly because C/C++ you have to handle a lot of the variable control yourself, such as destroying them when not in use). I would think that an optional side script type of C/C++ or C# instead of script step (with obviously the usage of the script steps in the language) would be an add-on (not replace) to scripting to allowing more advanced software with less effort- but that is not necessary if script steps could incorporate at least methods/functions (reusable scripts) at the least. I do not see a whole lot of use in object oriented programming with the script steps, just from my experience- but that could be useful for many things, but also make things even more complicated (putting functions/methods inside classes, class abstractions, class privacy and public access in methods/functions/variables...).
When you post to the general discussion part of the forum your posts will primarily seen as requests on how to use the product. In that respect, I and others have provided info on how we choose to work with product both its strengths and its weaknesses.
There are other sections here intended for providing feedback and for suggesting new features for the product. Your opinions are welcome here, but thought it might help to point out those other venues for providing product feed back that you can use if you wish.
I myself would welcome support for multiple, formal, typed parameters as part of the perform script call. I don't see the need to redesign the custom function tool to make that happen, however.
But, as I said at the start, 9 times out of 10 (if not more) I find that a simple use of List and getValue does the job and is easily self documented as well. I only need more complex approaches such as a JSON OR a custom function on rare occasions.