Sounds like you have encountered the one key limitation of list.
Lit ( FieldA ; FieldB ; FieldC ) could produce this list:
If FieldB is empty.
SO you have to be careful of the possibility that an expression, field or variable used as a parameter to list in your parameter expression not be a null or empty value as that will cause subsequent values to "slide up" one position in the list.
List is my preferred method for sending mutlple values as a script parameter as it's easy to set up and obvious in it's function, but sometimes this limitation causes me to use other methods. Sometimes, I can still use it if I have only one value that might be null and I then make it the last element of my list or if I modify an expression so that it never has a null value--maybe a space character instead of empty for example.
What's been funny about this is that although there are no null values, the more there is in a text field with spaces between the words or commas or numbers, is when it happens. That's why I was asking about a limitation in field quantity that was causing it. I'm also going to have to look more at global variables rather than trying to pass them as a script parameter.
Sent from Brad's iPad
Then I suspect that you have return or enter in that text as that also causes problems.
Field A = "A<return>B"
Field B = "C"
List ( Field A ; Field B ) produces:
note that either char (10) or char (13)
will work to separate values in a list.
+1 on the perils of trusting "List" to know what you meant.
While it may be "OldSchool" I like to build my parameters by ¶ stacking and assessing each additional row to the stack for linefeeds. Also like to TRIM those as well. When I do detect linefeeds I swap them for the "|" character and add a comment as part of the parameter that I did this (using predictable terminology). At the other end I watch for parameter comments and have handler routines to deal with them.
Way more code but it works. Helps to have lots of commenting in it.
“There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code. ” - Flon's Law
1 of 1 people found this helpful
Perhaps the single greatest piece of advice I ever followed as a FileMaker developer was adopting Jeremy Bante's name-value pair custom functions: Custom Functions » Script Parameter Interface - Best Practices - FileMaker Coding Standards
Looking at my early scripts I shudder when I see GetValue ( Get ( ScriptParameter ) ; 4355 ). Hyperbole, of course, but do yourself a favor and look over those functions. Worrying about list order, carriage returns, null values, etc... is not worth the slightly simpler list approach.
Edit: In fact I think 'slightly simpler' is too generous to list (). All using list () accomplishes, in my opinion, is saving you the time of installing those custom functions.
I have only used the semi-colon and a space between items in List.
+ 1 for this. Couldn't live without it now.
To each their own I guess.
List ( parameter expression 1 ; // Name
Parameter expression 2 ; // Street
Parameter expression N ; // HireDate
) // List
Set Variable [ $Name ; GetValue ( Get ( Scriptparameter ) ; 1 ) ]
Set Variable [ $Street ; GetValue ( Get ( Scriptparameter ) ; 2 ) ]
Set Variable [ $HireDate ; GetValue ( Get ( Scriptparameter ) ; 3 ) ]
works for me over 90% of the time with no need for custom functions. It's only in cases where I get more than one possible null parameters or a parameter that itself is a list with a variable number of values that I have to change my approach.
Another “burn” can be extracting via GetValue() where you put in a number on one side but get out text that you think is a number on the other side. And then using that as a number while FMP treats it as text. So you can get 2 > 19 in some cases which is true in the text world but wrong in the number world. So I ended up using GetAsNumber( GetValue( Get ( ScriptParameter ); 14)).
Yes, the occaisonal getasnumber, getasdate or getasTime function is needed.
There was always something I didn't like about these particular functions in 'Standards'; probably the use of the hash/pound? So, I don't use them.
There was something passed around from some old (previous) FMI folks, though I cannot find the source now.
It involves passing name/values with the "=" between them. This allows quoting of the values, so that returns are preserved.
Example, NOTE: the square brackets here are replaced with |, because reply by email, does something funky with them:
Perform Script | "CREATE blahblah" ; Parameter: "blahID=\"" & blahID & "\"; blahName=\"" & blahName & "\"" |
this, of course evaluates in the script parameter as
blahID="12345"; blahName="Billy George Smith"
so it can be evaluated in the other script:
Set Field | myNewfieldID ; Evaluate( "Let( |" & Get(ScriptParameter) & "|; blahID)" ) // end eval |
Set Field | myNewfieldName ; Evaluate( "Let( |" & Get(ScriptParameter) & "|; blahName)" ) // end eval |
At one point I started making the 'name' as $Vars, so that just evaluating the script parameter this way, "created" the new variables in the other script using Set Variable. The Evaluate() sets up the Let() so it becomes a "calculation" that can be used normally, but is really a ScriptParameter!
And doing this 'manually' takes some work, so perhaps someone came up with Custom Functions to handle (write and read) these more elegantly. Wendy King?
Anyway... There are so many ways to pass these (probably as many as there are developers!) There are many requests in @Ideas to pass multiple parameters.
It looks like the addition of JSON functions (as noted in Product Roadmap, under the Resources menu above), may indeed allow the generation and parsing of JSON more easily. The Name/Value pairs this way are quoted in name and in value with a colon between them and other separation between pairs. Perhaps even arrays?
That would be a great way to pass multiple parameters at once. We shall see.