you can 'escape' unwanted characters like the 'CR'. Replace the CR with something like #cr# when filling the $var - and 'de-escape' that when getting the value of the param. (There are other methods as well)
It would look like this: Use the Substitute() function when you pass your parameter to turn it into your carriage return substitute:
Substitute ( address ; "¶" ; "||" )
Then again in your function to decode:
Substitute ( get(scriptparameter) ; "||"; "¶" )
Good idea, but the double-pipe (||) may be used in content. Before using that, I might try Char(182). This is the iconic pilcrow, but would not be "translated" by FM as the "return symbol" - Char(13) - would.
Substitute (myText ; Char(13) ; Char(182) ) // to set
Substitute (myText ; Char(182) ; Char(13) ) // to unset
-- sent from myPhone --
I suggest you consider using name-value pairs instead of the position of the value in a list. It's faster and not vulnerable to a change in the parameter structure. Here's one implementation:
I suggest to use a method on your fields which removes any carriage returns on data entry, plus a replace contents run to clean up existing problems.
Sorry, I opine that's a silly assessment. Fields should be allowed to have returns. The "problem" is when trying to move that data somewhere else (Export, pass as parameter, web publish, sharing otherwise, etc.). Because we don't have control, we have work arounds. But within the field? Char(13) and any other character should be 'legal' (not garbage).
You could do this when setting the script parameter:
getValue( CONTACTS::name ; 1) ;
getValue( CONTACTS::address ; 1) ;
getValue( CONTACTS::phone ;1)
Return characters in contact fields are garbage. A good developer however makes sure that input of return characters is not possible where it's unwanted
I strongly disagree.
It is very often the case that a field absolutely should not have embedded or trailing returns.
An auto-enter calc should be set up for these fields to remove them, and a find and replace operation should be performed to fix existing data.
depends on the field. yes, auto-enter and validation are good ways to ensure good data. Let's not throw garbage into passing script parameters.
true! Bruce, your use of List() (as well as by OP), above, does introduce returns into a value. This may be passed, this may be displayed, this may be used in other ways. I'm not refuting in some fields there should be no returns. But the question is about passing parameters.
The work-around is to substitute out these values (when passing parameters), if the data has them (regardless of the field).
I do not see your point.
The method I described solves the problem.
It allows a return delimited parameter to be passed; and allows each element of the parameter to be captured successfully by the script using the original technique of the script.
If any element of the original data had trailing returns, they are excluded.
It does not fix the original data.
It does have the limitation that original data can't be empty for any of the fields in question.
you are entitled to your opinions, including that "silly".
Of course "fields" should be allowed to have returns in them.
If they are love letters, not if they are phone numbers, let me add.
If a solution is being built from scratch it probably is a good idea to prevent unwanted tabs, returns etc. etc from being entered. Also if you inherit a solution from your customer, it maybe is wise to cleanse that data and make sure on future entry, these unwanted characters are avoided.
OP would like to have a method to parse multiple parameters into a script, either from one script to another or from a button, without messing up the existing script. The suggestion made by Mike_Mitchell is actually a pretty good one. Only thing is that the explanation on modularfilemaker and http://filemakerstandards.org/pages/viewpage.action?pageId=557462 is maybe a bit too elaborate for a lot of people.
I use a similar method (only in a lot simpler form than the one explained over at fm-standards):
p ( name ; value )
";$" & name & "=" & Case( value > "" and Exact ( GetAsNumber( value ) ; value ) ; value ; Quote( value ) )
This function transfers any piece of data in a string.
If you need to parse more than one paramater you can simply concatenate them like this:
p ( "var_number" ; -175.12 ) &
p ( "var_date" ; Date ( 2 ; 2 ; 2016 ) ) &
p ( "var_text" ; "Some text" )
And this is turned without any further effort into:
This function does not care which kind of data is feed into it, it also doesn't cleanse the data, it converts it all into text only.
On the receiving end this single string must be evaluated to create variables from it that can be used in that script. This is done with this custom function:
EvaluateLet ( parameter )
Let ( [
l = Length ( parameter ) - 1 ;
param = Middle ( parameter ; 2 ; l ) ; // first ";" is stripped from parameter
result = Evaluate ( "Let([" & param & "];1)" ) // parameter is evaluated, if error, result is "?" otherwise "1"
If you call the parameter $var_number the result will be -175.12 (which is a number-result)
If you call the parameter $var_date, the result will be 2/2/2016 (but as text-result! If you'd need it as a date the call should be: GetAsDate ( $var_date ) )
Note 2 things when you use this:
1) any variable created like this is either a number or is text! Dates, times and timestamps must be converted before use! If you do not, the result is always text!
2) If you have for some reason, more than 1000 variables, this function does not work anymore. (I created Evaluate-Let 2.0 to handle that problem, but I think that's not the scope of this post nor OP)
Anyway, I hope it may be of help to you and as Siplus said YMMV (i had to look up the meaning of that :-) as i'm not native english speaking)