Dave Graham Posted January 19, 2009 Posted January 19, 2009 (edited) There are two great options here and here for passing and retrieving multiple script parameters. Both options have a lot in common, and it's easy to write script parameters which utilize these custom functions. I got tired of having to explicitly retrieve the many different parameters and wanted to instantly have all of my parameters available so I could tell immediately if I had any problems during debugging. This is why I wrote my own custom function which converts a multiple-parameter string instantly into multiple populated variables. It's easier to screw up the parameter string, but the end result is worth it for me at least. Take a peek and tell me what you think. param_demo.zip Edited January 19, 2009 by Guest Forgot the topic prefix
Ocean West Posted January 19, 2009 Posted January 19, 2009 Awesome! - One thing i was thinking of too is to make global variables so that you can if needed pass it to subscripts - like a script that does GTRR spawning a new window the only thing you need to put into the dialog for the new window is global variables like $$title $$top $$left $$height $$width which all were set from the calling script. Thanks for sharing :
Dave Graham Posted January 19, 2009 Author Posted January 19, 2009 One thing i was thinking of too is to make global variables so that you can if needed pass it to subscripts - like a script that does GTRR spawning a new window the only thing you need to put into the dialog for the new window is global variables like $$title $$top $$left $$height $$width which all were set from the calling script. Good idea! The CF in this demo will let you instantiate global variables as well, but as a general practice I don't do it for a few reasons: 1. Globals are only available in the file that they've been instantiated in. A lot of my projects are conversions, and even some of my new projects have multiple files by design. In your case, window properties as you mentioned are fine of course, but other might not. YMMV. 2. The more globals you use, the more potential for name-space conflicts. 3. Nearly everything that you can do with global vars can be done with local variables, even if it does require a little extra work. For instance, if you wanted to pass variables to a script for use in a subscript you could pass them to the parent, and the parent can pass them to the subscript. There are of course some unique applications of global variables such as SeedCode's BackMagic solution. NB, BackMagic still suffers from issue #1 (above). Thanks!
fabriceN Posted January 19, 2009 Posted January 19, 2009 Just one more (same 'idea') I use xml-like structure with custom functions. xmlSet to easily write xml http://fmfunctions.com/fname/xmlset xmlGet to grab some an xml node (if the contents starts with a =, it's evaluated, which is something I use a lot) http://fmfunctions.com/fname/xmlget xmlGetWhere to grab nodes where a value matches your request http://fmfunctions.com/fname/xmlgetwhere xml2var to quickly parse the xml parameter into named script variables http://fmfunctions.com/fname/xml2var
Recommended Posts