Jump to content

Oddball question about Closing a file from another file


This topic is 5766 days old. Please don't post here. Open a new topic instead.

Recommended Posts

I am trying to figure out a way to close a file from another file without having a File Reference defined for the file I want to close.

The Close File script step requires a static File Reference instead of allowing us to specify the file reference dynamically using a variable to specify the file to close.

The Perform Script[External] script step is the same way which makes sense.

The reason I am trying to do this is because I have a client that uses Terminal Services to access the application. The application is designed to have a local GUI file on each workstation while the data is on a server. Essentially, each user has their own GUI file.

In a non-Terminal Services environment it's no problem at all. I just store the GUI file in the FileMaker Extensions folder and use FileMaker's AutoUpdate program to update the GUI file.

However, in a Terminal Services environment, the FileMaker Extensions folder is a common folder between each session/user so I store the GUI file in the user's preferences directory. Using the Get(PreferencesPath) function this is not difficult at all and works out great except when I try to close the GUI file via a script to replace it with a newer GUI file. In essence it's an update.

When the update runs, I run a script in the GUI file that runs an external script in a file on the server that takes care of the replacing of the file. Everything works great except that I can't get the GUI closed from the file on the server without having a static File Reference for the GUI file.

I can't have a static File Reference because each user has their own GUI file in their preferences directory. I can get the path to the GUI file dynamically with the calculation engine, but I can't use that to close the file.

I have tried looping through the windows to close any windows belonging to the GUI file which will close the GUI file. That didn't work because I was running the script in the external file and apparently the Close Window[] script step will only close a window if it's in the same file as the currently running script.

I thought of moving that looping script to the GUI file, but in order to run it from the external file I need a static file reference to the GUI file.

I can't close the GUI windows before running the external script, because closing the GUI windows closes the GUI file which essentially Halts the script.

It's a vicious circle. Any suggestions would be great.

Link to comment
Share on other sites

Woohoo! I found a solution!

I stated in my original post that the Close Window[] script step will only close a window if it's in the same file as the currently running script.

What I found, however, is that if you explicitly name the window to close in the Close Window[] script step, the window will close regardless of what file the window is based UNLESS you select the "Current File only" checkbox in the Close Window[] script step.

In my case, I don't mind closing all the windows except the window that is active when the script is called.

So, my script for closing all the windows looks like this:

Set Variable[$window_Start; Value: Get(WindowName)]

Set Variable[$num_windows_Open; Value: WindowNames]

Set Variable[$counter; Value: 1]

Loop

If[GetValue($windows_Open; $counter) <> $window_Start]

Close Window[Name: GetValue($windows_Open; $counter)]

End If

Set Variable[$counter; Value: $counter + 1]

Exit Loop If[$counter > $num_windows_Open]

End Loop

Works great.

Link to comment
Share on other sites

This topic is 5766 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.