Jump to content
Sign in to follow this  
Mandu

Maintain lockstep between Applescript and FMP?

Recommended Posts

How do you keep AS from proceeding until the FM script it has initiated has actually completed? Below is a snippet from my AS. The dialog pops up immediately, long before the Filemaker script has finished.

try

tell application "FileMaker Pro"

tell database pFMMasterFile

do script pFMScriptImport

end tell

end tell

on error errMsg

error errMsg

end try

display dialog "Hello from Applescript - has the Filemaker Import finished?"

Share this post


Link to post
Share on other sites

This is where you either use an AppleEvent or you split the script and use a returning script from Filemaker.

try:

http://www.macscripter.net/

for AppleEvent and script refernces.

Love to know what you get accomplished.

Share this post


Link to post
Share on other sites

What I ended up doing was creating another FM script, "Sync", which simply calculates Count(somefield). I called that immediately after calling FMScriptImport, on the theory that FM might refrain from executing Sync until the Import was finished. That appears to work, although I don't know whether *anything* would have worked for Sync, or whether it needs to contain a dependency on the previous step being completed before being able to compute a result accurately, or whether this is bogus and I've just been lucky with timing so far.

I'll go with that for now, but if anyone knows how FM handles a series of Applescript requests for FMscripts, I'd be very interested to know.

Share this post


Link to post
Share on other sites

You're usually better off doing it the other way around. Unless the FileMaker script is the last step of the process; in which case you DO want to have AppleScript tell FileMaker to run the script, because in that case AppleScript may not be finished yet.

If it's a long complicated process, you can pass control back and forth. Use a FileMaker script to start a process; then run a Perform AppleScript step; which, at its end, calls a FileMaker script. The FileMaker script then does some FileMaker stuff; then runs another Perform AppleScript to do more AppleScript stuff, which calls a FileMaker script, etc..

In other words, let FileMaker handle the overall control.

You can also pass lists of things to AppleScript, such as a list of file names to do something to, from a FileMaker found set, so AppleScript can process them all at once, without needing to ask each FileMaker record for more data.

The one thing you don't really want to do is to run a Perform AppleScript step, then run a FileMaker script, in FileMaker, which requires the result of the AppleScript.

Or conversely, to call a FileMaker script from an AppleScript, which then continues, expecting something back from FileMaker. That would be kind of crazy.

The main downside to passing script work back and forth is that the names of the scripts will be hard-coded into the AppleScript. Field names can be problematic also; and layout names, etc..

Share this post


Link to post
Share on other sites

Thanks, Fenton,

First, my solution apparently does *not* work. I wanted to close the FM file and quit Filemaker after the Import, so I added two statements to my "Sync" script: Flush Cache, and Quit Application. That left me with a corrupted FM file.

This is an installer. I'm trying to write an Applescript (saved as an Application Bundle) that installs and initializes a FM database which is stored down inside the Bundle. (Installer.app:Contents:Resources:MyDatabaseFolder:People.fp5, etc.) So it certainly demands that the process at least *begin* in Applescript.

It sounds, from what you wrote, as if Applescript-calling-FilemakerScript and FilemakerScript-calling-Applescript both result in two asynchronous processes: one running the AS, and one running the FM script. Is that correct?

When a standalone Applescript says

Tell Filemaker to do script A

Tell Filemaker to do script B

does FM run A and B serially, or concurrently?

Share this post


Link to post
Share on other sites

What I'm saying is to let FileMaker handle most of the timing. Pass control one script at a time between them. Neither FileMaker nor AppleScript can run the whole show independently. Because neither can tell if the other one is done with its current task. One way to be sure is to start in one, then, at the end, call the other, then call the original back FROM the one that was called, etc..

A FileMaker will only run 1 script at a time. Obviously. An AppleScript will run its steps, more or less from top to bottom.

Run a FileMaker script (0); last relevant step is Perform AppleScript 1.

AppleScript 1 runs; last relevant step is do script FileMaker script "Script 1"

FileMaker "Script 1" runs, last step is Perform AppleScript 2.

AppleScript 2 runs, last step is do script FileMaker script "Script 2"

etc..

So, in your case, you want a stand-alone app built in AppleScript. So, let it call Script 0 in FileMaker. Then you're off and running. You could always include a single FileMaker file which calls external scripts in other files, and has most of the AppleScript code inside Perform AppleScript steps. So, your "installer" is a dual AppleScript-FileMaker combo.

There are AppleScript experts (BruceR) who could probably do this all in AppleScript, using Idle statements and such. But I don't know how.

Share this post


Link to post
Share on other sites

So, in your case, you want a stand-alone app built in AppleScript. So, let it call Script 0 in FileMaker. Then you're off and running. You could always include a single FileMaker file which calls external scripts in other files, and has most of the AppleScript code inside Perform AppleScript steps. So, your "installer" is a dual AppleScript-FileMaker combo.

Ok, I'll try that. Thanks...

Share this post


Link to post
Share on other sites

It was easy enough to convert to a sequence of scripts as suggested. My only concern is with the following sequence at the end of the standalone Applecsript: can Launching FMP, Opening People.fp5, and firing off the FM script for the next stage can be counted upon to happen in a good, serial fashion?

I know that Finder:Launch is documented as not completing until the app is fully initialized, but I don't know that about Filemaker:Open. Will it, too, wait until the database is open and ready to accept the 'do script' event?

try

... tell application "Finder" to launch application "Filemaker Pro" -- start FM and wait until open

... tell application pFMApp to open gPathToFMMasterFile -- open People.fp5

on error errMsg

... display dialog "Problem launching " & gPathToFMMasterFile & return & return & errMsg

... error errMsg

end try

-- Run the Import script, then quit Filemaker

try

... tell application "FileMaker Pro"

...... tell database pFMMasterFile

......... do script pFMScriptImport -- run Import script in People.fp5

...... end tell

... end tell

on error errMsg

... display dialog "Error running Import: " & errMsg

... error errMsg

end try

-- end of Applescript --

Share this post


Link to post
Share on other sites

Here's a couple thoughts. First, this is not something I've done, as I tend to use FileMaker to control things.

In a short test I seem to have no trouble using AppleScript to launch (not activate) FileMaker, open a database file, and call a script in it. It's possible that these commands can be called safely one after the other, because none of them expects or needs to get anything back.

Another idea; could the pFMMasterFile have a startup script to trigger the Import script in People.fp5? Or does the pFMMasterFile not know the location of the People file?

If you're really stuck, and the process you're calling in FileMaker has a fairly predictable time frame, you can use something like:

delay 5

to give AppleScript a 5 second timeout. It's a little (to a lot) clunky, and wastes some time. Really a last resort sort of technique. Prone to failure if conditions cause something to take unusually long.

There's trouble if the file you open has a start-up script. Here's a short test. Create a Startup script, just Pause [5]. Create another FileMaker script, to call from AppleScript, say a quick Dialog.

When you open the file, the Pause will start, the quick Dialog will display immediately; without waiting for the Pause to stop; you click OK, it goes away. But the Pause never stops. It's as if it got cut off when the 2nd script began, still running, never to finish. A little spooky.

If you put a delay 7 in the AppleScript, so that the Pause has time to run out, then it's all fine. But you'd have to get that timing just right.

Share this post


Link to post
Share on other sites

Thanks, I was wondering whether a long startup script could affect things.

When timers are involved in maintaining synchronicity, it's time to rethink things.... What I ended up doing, which seems to work and feels a lot safer, was to replace the "Launch Filemaker / Open MyDatabase.fp5 / Do Script Import" sequence with a single 'tell app "Finder" to open document "MyDatabase.fp5"' and extend the startup script to say "if no records then run the import script".

I like the idea of having an extra database whose purpose is to house scripts and control the real database, but didn't need it in this instance.

Incidentally, someone else suggested the same "Sync" script that I described above. I think it actually does successfully block AS from proceeding until the penultimate script has finished. The problem I was having was that Sync was doing Flush Cache, a potentially long operation following an Import. Meanwhile, Applescript had resumed and was busy moving the database to another location! Small wonder it got corrupted. But if Sync was truly a no-operation, it might be a dependable way to achieve lockstep between AS and FM scripts.

Share this post


Link to post
Share on other sites

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
Sign in to follow this  

×

Important Information

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