Simple layout with a button bar. Each button is named after a file and the file name is what is input in the Script Parameter.
What I want is very simple. I want the file to open when I click the button. Instead of repeating If bla bla bla 40 files time, I made a simple script:
Set Variable [$file_toOpen; Value: Get (ScriptParameter)]
Set Variable [$$filePath_toOpen; Value: "file:" & $file_toOpen]
Open File [Open hidden:Off; "FilePath_toOpen”]
Note: I initialize OFWO of the file (main) which runs this script, I set the $$filePath_toOpen to "file:main.fmp12" which prevents the script to end up with « unknown » where the name "FilePath_toOpen" of the variable path should be.
When clicking one of the button the first time, the correct file opens. After that it is always that same file that opens despite the DataViewer showing me the correct values in the variables.
What did I miss?
Too many external references. The path gets "glued".
I give up the method.
You can choose what file to point to and use that in a variable. That said, once your file where the variable is defined resolves the link to the external file, you are bound to that assignment for as long as your file (the one where the variable is defined) is open.
Changing the variable contents will not affect other calls to the external data source after the initial link has been established, even if you close the other file (the file you pointed to).
So it does vary, as you are able to choose what to link to, before any calls are made to that external data source, and not rely on multiple hardcoded references to distinct external data source.
It does not vary after FileMaker has resolved the external data source.
Interestingly, if the initial attempt at opening the destination fails (wrong path or file name, the user is prompted for credentials and cancels out, etc.) you can still re-assign the variable contents and bind to a new file. But once an association is done, the only thing that will break that link is to close the file from where it was established.
To add to what @Bobino wrote you of course iterate the $$filePath_toOpen or don't you? I use this technique to update runtime solution data files and it works fine and stable with different external data sources bound by variable paths. The user only has to choose the directory of his backup and everything else is done in a loop calculating the paths and establishing the links.
Yeah. After plenty of testing, we discovered this contingency.
In the solution, several of the external file have dependencies. The iteration works with a hard coded close file or set variable to the calling file, as long as the external file called doesn't have dependencies. When they have, they end up gluing tons of hidden files to the main file. It only works if I close the calling file. But then, getting it to reopen becomes too convoluted.