I have a button on a portal that calls a script "Show_Container": 

Line 1:   Set Variable [ $Param ; Value: Get ( ScriptParameter ) ]        (name of container field is passed thru script parameter)

Line 2:   Set Variable [ $Path ; Value: Get ( TemporaryPath ) & GetContainerAttribute ( $Param ; "Filename" ) ]

Line 3:   Export Field Contents [ Table::Field ; ""$Path"" ; Automatically open ]

 

Wanting to reuse this script in multiple places, I need to be able to replace the "Table::Field" in line three with a variable, but can't see how to accomplish this.

Any ideas?

Thanks,

John

 

 

Edited March 13, 20169 yr by Woodeye

Before looking for a solution to the problem as presented, I would ask why this problem exists in the first place. To me, it sounds like you have multiple fields where you should have multiple records in a related table.

I could easily rewrite the script for each layout/table it would be used in (the script is only 3 lines). What I am trying to do is get better at writing reusable scripts. In this case, I don't see how I can do this.

 

A small amount of Google-fu suggests:

http://gearboxgo.com/blog/a-smart-way-to-export-field-contents-part-1

You're not answering my question: the fact that you want this script to be reusable indicates a structural issue. It will be easier to solve the structural issue than to make this script reusable - not to mention that the structural issue will remain to cause you many other problems.

The target field of Export Field Contents[] cannot be parametrized. The only way to make this work the way you describe is to make sure that the required field is the currently active field - then use Export Field Contents[] without specifying the target field. You can make the required field active by looping among all fields in the layout's tab order until the active field's name is equal to the script parameter. Or give the field an object name and use Go to Object[] to make it active. Both are hacks designed to work around the real problem. And, IMHO, so is the solution linked to by @webko.

I'm not sure it has to be a structural issue - I can think of a number of scenarios where I have container fields in different tables that I would like to Export - having one script to perform that function, rather then one for each Container field seems logical to me...

I am obviously not only a failure at FileMaker, as I should have thought of using a global field. I am now conflicted as to whether to sign up for training in FileMaker or have someone teach me to use a Google search properly. 

Thank you for the help.

Hi Woodeye, and welcome to the FMForums,

I posted a couple of links to training sites the other day here.