Not as far as I know...
You might try passing the name of the field's value list as a script parameter to your script.
fileName- the name of an open (local or remote).
layoutName- the name of a in the specified database file.
fieldName- the name of a on the specified layout.
Important See Design functions for information about literal text parameters.
Data type returned
Returns the field formatting applied to
fileNamefile. If the field has a value list associated with it, the
FieldStylefunction also returns the name of the .
Might be worth re-considering: 'Why would you want to be changing the name of a value list?'
I don't think he's changing it, just wants to create a script that can interact with a value list without specifically naming it in the script.
Phil is right. I'm trying to make a generic script to handle a quick jump menu in a drop down. The value lists in the drop downs that will use this script are different, and the scripts are on different layouts, calling different layouts etc.
It's either passing variables as parameters to the script or having a long list of hard coded if then statements with hard coded values.
The trouble with sending a variable like a layout name or value list name in a parameter is that filemaker doesn't update it if I change that layout name or value list name later.
I think Raybaudi has the answer here. It looks like you can use get functions to extract the needed parameters for that design function in order to then get the field's value list name.
BTW, parameters can be calculations so you don't have to "hardwire" references to field and layout names as you can put get (layoutName) and GetFieldname (table::Field) functions to return those names as your parameters...)
"BTW, parameters can be calculations so you don't have to "hardwire" references to field and layout names as you can put get (layoutName) and GetFieldname (table::Field) functions to return those names as your parameters...)
Exactly. So, is that not 'dynamic'...?
Thank you. I realize that parameters can be calculations - however, if my parameter includes a layout name that I want to open in the script, then unless that new layout is related somehow to the current layout, I can't calculate it.
Example: a drop down box located on my home screen. On object exit, it fires a script to go to an account with the name listed in the drop down box. It goes to the "accounts" layout and performs a find given the name in the drop down box. I don't think there is a way to calculate the "accounts" layout name, or derive it from anything on the home layout. Maybe 100% automation is not good anyway....
Given how each layout references a specific table occurrence and that, in turn, sets up the current found set, current record and sort order such "automation" might not be a good thing.
That said, the value selected in the drop down could be used to calculate a layout name or layout number that could be used in Go To Layout so that the drop down controlls the layout destination and you don't need a stack of If-Else-IF's to make it happen. It does require a table of layout names or numbers that also includes some additional field so your script can use the selected value in the drop down to figure out the name or number to use, so it's still not really free of the "hardwired" aspect that bedevils so many FileMaker scripts.
Read the following article on FileMakerHacks.com: https://filemakerhacks.com/2011/04/18/avoiding_brittleness/
There is a very useful custom function called FM_Name_ID that you can use to get the internal FileMaker ID of various objects (Fields, Tables, Layouts, ValueLists, and Scripts). Then, you can send in the ID of the value list into your script and it can then turn that ID back into the current NAME of the value list. So, if you rename the value list, everything will still work.