• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Parameter Pandamonium

Page history last edited by Darren Terry 14 years, 3 months ago

This will be an open discussion of different techniques used for passing parameters to scripts and instantiating variables based on those parameters. Topics covered will include a survey of various Custom Functions for instantiating variables based on name/value pairs, as well as more brute-force approaches.  There will also be an overview of treating scripts as if they were functions (and naming them in function-standard syntax).  The pros and cons of the various approaches will be compared and contrasted.

 

Since this is an open discussion, audience participation will be encouraged.

 

Host:  Darren Terry, Pacific Data Management, Inc.

 

 

This session was inspired by a discussion among certain high-level developers on an elitist list.

Comments (14)

Stephen Dolenski said

at 9:49 pm on Jul 29, 2010

just a follow up thought you'd all like this idea...

if your using 360Works ScriptMaster set a startup variable to this...

RegisterGroovy( "SetProp (varName ; varValue)" ; "System.setProperty( varName, varValue);" ) &
RegisterGroovy( "GetProp (varName)" ; "return System.getProperty(varName);" )

Whats nice about this is that its scoped for the session for the user across all open files. - UNIVERSAL VARIABLES no relationships required.

Thanks Jesse for the code ;)

Chiyoko Yoshida said

at 1:31 am on Jan 30, 2010

Enjoyed the Demo file and techniques. Thanks much! I have to say I use the brute force method myself after tiring of creating custom functions to XML wrap and unwrap. Using the stack is cumbersome too when you get a lot going on. I have to say avoiding custom functions is a benefit when dealing w/ many files and of course dealing with the need for portability. Good stuff.

David Lalonde said

at 9:32 pm on Jan 21, 2010

By popular request, you can find my typedDictionnary functions at http://www.d-cogit.ca/Files/typedDictionnary.zip. I understand this could have been an addition to the Parameter Pandamonium session but I have not posted this on my WEB site or advertised this anywhere. The example FileMaker file shows how to use this to automate the creation of script variables. As I explained in the session, the typedDictionnary function implement a typed dictionnary and is inspired by Apple's collections framework in Cocoa. I am thinking this could be a presentation on its own. The topic is technical. Is anyone interested?

John Sindelar said

at 2:59 pm on Jan 19, 2010

Just saw your note Darren; I like that. Thanks.

Stephen Dolenski said

at 2:41 pm on Jan 19, 2010

Loosely thinking if you encapsulate your parameterized string by opening and closing tags - something that would never normally appear in a window title like

Customers - 6
Customers - 5
Customers - 3
<#>
$$MyVar=1; $$SomeVar[4]=7200; $$AnotherVar="\xyz\";
</#>
Customers - 4
Customers - 2
Customers

then parse the WidowName function with a script or CF that extracts the contents and returns the string for window targeting:

<#>
$$MyVar=1; $$SomeVar[4]=7200; $$AnotherVar="\xyz\";
</#>

Bruce Robertson said

at 1:39 pm on Jan 19, 2010

How do you address this window?

John Sindelar said

at 12:27 pm on Jan 19, 2010

... the car is skidding off the road. ;-)

Stephen Dolenski said

at 3:08 am on Jan 19, 2010

I had an epiphany that perhaps we could discuss or explore in more details a technique that could prove to solve a longtime shortcoming of FMP  — parameters & variables scoped ONLY for the current file.

In a nutshell the concept is this.... TRULY UNIVERSAL PARAMETERS & VARIABLES that can be available by any open database ( such as the separation model ).

FileMaker will allow a fairly large amount of text (30,000 characters ) when creating a new window or setting the window title via a script including the use of ¶ (pilcrow) therefore you could create a window off screen, naming the window with some uniquely organized / structured list of variables ~ parameters and matched strings. Then when in any other database return the list of all open window names by using the WindowNames {( )} function, optionally targeting the primary file if necessary.

A CF or script in each file could be used to retrieve the value stored in the 'solution scoped' parameters/variables parsed from the WindowNames function. Some method would be needed to create a namespace for the window used for storing the parameters. Should you need to target that window to focus and edit its title. In addition adding a few ¶¶ at the beginning of the window title will prevent data from showing should the window some how not draw off screen ( at least on MAC - not tested on WIN).

Side note since you could create window names with the ¶ you can also uniquely identify each window that is created and hide that meta data as the user would only see the first row - in theory.

I have been busy moving so I have not had the time to come up with a full working model / example...

Feel free to comment & discuss can't wait to see what develops.

Stephen

Darren Terry said

at 10:29 pm on Jan 18, 2010

John, I noticed that in the script you posted, in the Let statement (where you're setting $parameters), you're defining e to check for the non-occurrence of the string " = " in the script parameter. But you're not using e to do any error checking in the posted version of the script.

My guess is that you were intending to have the Let's actual formula be a Case statement checking for e, no? And if e, then return something like "\"error\"" (which would evaluate to the text string "error", which could be checked in the calling script), no?

If it's OK with you, I'm going to incorporate that error check into the example script I include in my demo file, OK? Let me know.

(Actually, what I'm planning to do is have the Let include a Case statement like this:

Case ( e ; "\"1\"" ; "Let ( [ " & prefix & string & "\" ] ; \"0\" )"

Then, in the calling script, I would do this:

Perform Script [Parameters to Local Variables ; Get ( ScriptParameter )]
Set Variable [$parameters ; Evaluate ( Get ( ScriptResult )) ]
If [ $parameters ]
#Error trapping here and exit script
End If

How's that sound? (This is an unabashed rip-off of Geoffrey's idea, where there's an error check in case there's a problem).

Let me know what you think.

Don Levan said

at 1:26 pm on Jan 12, 2010

Hi John,

Thanks for sharing your script. Somehow I missed this (I believe you posted it just before I left for a family vacation).

Darren Terry said

at 12:52 pm on Jan 12, 2010

I really like the idea of encapsulating the custom function logic in a script, and referencing that instead. I'm a big proponent of using scripted functions in favor of custom functions. And I really like the elegance of your solution, John.

John Sindelar said

at 2:08 pm on Dec 22, 2009

Here it is:

SeedCode Calendar: Calendar Utility: Parameters to Local Variables
#Declare script paraneters as local variables.
#After calling this script, call the following in your script to instantiate the variables:
#SerVariable [$parameters ; Value:Evaluate ( Get ( ScriptResult ) )]
#
If [ IsEmpty ( Get ( ScriptParameter ) ) ]
Set Variable [ $parameters; Value:"empty" ]
Else
Set Variable [ $parameters; Value:Let ( [
n = Get ( ScriptParameter ) ;
prefix = "$sc_" ;
e = PatternCount ( n ; " = " ) = 0 ;
string = Substitute ( n ;
[ " ; " ; "\" ; " & prefix ] ;
[ " = " ; " = \"" ]
)
] ;
"Let ( [ " & prefix & string & "\" ] ; \"\" )"
) ]
End If
Exit Script [ Result: $parameters ]
#

Don Levan said

at 1:36 pm on Dec 22, 2009

Hi John,

I would love a copy of that script. We use the six fried rice custom functions - and love them - but hate that we must keep our custom functions up to date in multiple files. I have been looking for ways to centralize them for a while.

John Sindelar said

at 1:12 pm on Dec 22, 2009

I'd be interested to know what folks think of this....

We've been using a name value scheme like this-- "name = value ; anothername = another value" -- for a while now and unpacking it with a custom function, but in our new calendar we're avoiding custom functions to keep things portable. So, we've been replacing all our CFs with scripts and the ones for parameter passing are kind of cool.

In any script receiving parameters we include the following two lines:

#
#Declare script paraneters as local variables.
Perform Script [ “Parameters to Local Variables”; Parameter: Get ( ScriptParameter ) ]
Set Variable [ $parameters; Value:Evaluate ( Get ( ScriptResult ) ) ]
#

The script “Parameters to Local Variables” unpacks our parameters and creates local variables for each, prefixing the vars with our namespacing so "name = value ; anothername = another value" becomes $sc_name and $sc_anothername

This was inspired by Matt Petrowsky's custom function for turning inbound parameters into local vars of the same name. What I'm liking about this is that I can add some really nice messaging and error trapping to this script (and you'd need a script to do messaging anyway, even if your param scheme is all contained in a function). Anyway, would be interested in knowing what others are thinking about.

You don't have permission to comment on this page.