Dynamically Launching a FMP file from a container (self configuring)

[Charles Delfs]

Hello,

I have a need to 'spawn' a FMP file that is stored in a container to a location that could change (temp path)

Then Run that DB and pass it variables that will configure it,

Then take that now configured file and email it out.

 

Here is the issues I've run into,

I grab the temp path and pass it to the Export Field Contents step and select the option to Automatically Open, but this doesn't work. I know its not an issue with the file and path name etc. as the file is created and visible, also I can open other file types like PDF's and have them open after the export. 

 

Next I tried opening the file as I have done in other solutions with the 

Send Event 'odoc' - Open document step and this seems to have FMP hang for about 45 seconds then return an error but ONLY when its a .fmp12 file; with a .PDF it opens up fine.

 

The Issues is clearly getting to FMP launch another FMP file that is NOT referenced via the datasources.

 

Any Suggestions would greatly help.

 

Charles

 

[David Jondreau]

Is the file with the container field on the machine or is it hosted?

 

What comes to mind is to make a file reference and use Get ( DesktopPath ) instead of the temp path. Then you can just use a script.

 

And finally, or firstly rather, why are you doing all this? What is the user experience you're trying to achieve? There might be an entirely better way.

[Charles Delfs]

The purpose is to create a DB (a launcher in this case) that is configured with info that comes from the parent DB. There are various params that would be passed. The 'Parent' file is typically a single DB residing on a local desktop computer. 

 

I actually use the desktop path for debugging. But both desktop and temp path are not fixed and thus a datasource can not be used. (Variables in datasources are not allowed in the main datasources, only when referencing things like import and export paths etc)

 

Fundamentally the problem is: "How do you get filemaker to launch another filemaker file with a passed filename?"

 

 

Is the file with the container field on the machine or is it hosted? 

 

What comes to mind is to make a file reference and use Get ( DesktopPath ) instead of the temp path. Then you can just use a script.

 

And finally, or firstly rather, why are you doing all this? What is the user experience you're trying to achieve? There might be an entirely better way.

[Wim Decorte]

FM has an API that allows for this, through ActiveX on Windows and AppleScript on Mac.  So you could create a VBscript / AppleScript and have FM execute that, in turn it will instruct FM to open the other file.

[David Jondreau]

It's still unclear why you're taking this route. Why do you have this whole "file exporting another file" routine? Where do the configuration settings in the parent file come from?

 

Either the database is coming from you, so you can configure it beforehand, or the user is configuring the parent file, so they could configure the child. If this is some sort of file spawner, you can still store the settings in one file and have it make a clean copy of itself, keeping those settings.

 

Regardless, there is one way to eliminate the dynamic file path for external datasource issue...Have the parent file spawn the child file in the same directory as itself. Then the file path is simply, file: filename.fmp12

[comment]

I grab the temp path and pass it to the Export Field Contents step and select the option to Automatically Open, but this doesn't work.

 

AFAIK, this should work (I mean opening the file, not necessarily establishing a link with it as a data source). Perhaps there are some OS-level permission issues with the exported file?

 

 

Next I tried opening the file as I have done in other solutions with the 

Send Event 'odoc' - Open document step and this seems to have FMP hang for about 45 seconds then return an error

 

Well, what is the error?

 

 

Other than that, I too am puzzled what you're after eventually. As you noted yourself, variables cannot be used in data source references -  so it looks like you are deliberately walking into a blind alley.

[Charles Delfs]

It's still unclear why you're taking this route. Why do you have this whole "file exporting another file" routine? Where do the configuration settings in the parent file come from?

 

Either the database is coming from you, so you can configure it beforehand, or the user is configuring the parent file, so they could configure the child. If this is some sort of file spawner, you can still store the settings in one file and have it make a clean copy of itself, keeping those settings.

 

Regardless, there is one way to eliminate the dynamic file path for external datasource issue...Have the parent file spawn the child file in the same directory as itself. Then the file path is simply, file: filename.fmp12

 

The issue was not the path and file location but the launching of the file.

Here is an example of its use, an application that uses peer to peer sharing needs to create a self configuring launcher file (this is NOT the application itself) that when spawned will be able to be used by the office next door. Since the application is a vert market boxed app, it has to be able to work in different environments. This eliminates the need for the 2nd user to use the open remote box and reduces support. 

If something in the systems changes like a computer name or IP the user can simply spawn another launcher.

 

 

The issue with using the applications path is that it is possible depending on the deployment topology that the App is hosted on a server so its not a constant.

AFAIK, this should work (I mean opening the file, not necessarily establishing a link with it as a data source). Perhaps there are some OS-level permission issues with the exported file?

 

 

Agreed but the file doesn't open. Applescript look like the best option that does work. I suspect it is because FMP is already running a script while trying to launch a new file. Similar to trying to open a file while debugging another one. 

FM has an API that allows for this, through ActiveX on Windows and AppleScript on Mac.  So you could create a VBscript / AppleScript and have FM execute that, in turn it will instruct FM to open the other file.

Yes Agreed Wim, I have used this before but forgot about it. Thanks!

 

for future referecen this thread contains applescript that can be changed to launch a FMP file

http://fmforums.com/forum/topic/65742-quicklook-objects-in-container-field/?hl=applescript+coerce#entry413388

 

Well, what is the error?

 

The error was ' Unable to open file "?" '

A similar error happens if you are debugging a script and at the same time try to launch another file. 

 

CD

[David Jondreau]

Opener files are, in my opinion, completely unnecessary. You can create a simple link or desktop icon that does the same thing with a lot less overhead.

 

Regardless, the filepath is relevant because you can make the spawn file an external data source and use a simple "Open File" script in the parent. If the new file is in the same directory as the parent, the filepath will be the same across all machines and platforms.

[Charles Delfs]

Update FYI

I confirmed the issue with Auto open was that the FMP was busy with single stepping through another script. When the script terminates immediately after the update the exported FMP file opens. 

 

A work around this would be to install a timer that would allow the opening process to complete then continue running a continuation script to complete any needed processes.

 

C

[comment]

the issue with Auto open was that the FMP was busy with single stepping through another script. When the script terminates immediately after the update the exported FMP file opens.

 

Are you sure about this? What script steps do you have following the export that would cause Filemaker to "forget" to open to file? I cannot reproduce the problem here. I would understand the active window not changing, but I would still expect the file to open and be listed in the Windows menu.

[Charles Delfs]

Are you sure about this? What script steps do you have following the export that would cause Filemaker to "forget" to open to file? I cannot reproduce the problem here. I would understand the active window not changing, but I would still expect the file to open and be listed in the Windows menu.

how have you tried to reproduce it?

Try this, script an export container - automatically open, followed by a few other steps

single step through the export and see what happens, I found that the file does not open (the file must be a FMP file)

 

Another test is to take any file and debug step through the file, (or have a long running script)

Then open another FMP file from say the desktop.

In my tests, an error happens AFTER the script completes indicating the file cannot be opened.

 

C

[Charles Delfs]

Regardless, the filepath is relevant because you can make the spawn file an external data source and use a simple "Open File" script in the parent. If the new file is in the same directory as the parent, the filepath will be the same across all machines and platforms.

Thanks for your feedback David, but the parent file could be located on a server or locally. So I don't think this would hold true?

hmm maybe the application path but FM doesn't search there by default I don't think ...

c