I may be ignorant, but there I have difficulties understanding the scenario:
You want the FileMaker (runtime) closed. Therefore you want an Applescript to force quit your runtime solution.
Your approach is problematic. OK, I understand that you do not care about the data. But I am trying to understand. Is this somewhat correct:
- You need this routine to run at intervals or when something happens?
- Your Runtime solution starts up, pull in an xml file via ftp, does what it should and deliver the result via ftp.
- Then you want an AppleScript to force quit the solution.
For you this is working with a runtime, but the AppleScript does not work for you with the FileMaker Pro client.
Your problem is that Applescript seems unable to force quit FileMaker Pro, while it will force quit the runtime.
I am not writing this to be rude. But is it possible that you are not very familiar with FileMaker?
Maybe my answer would be different if you had described what you want to achieve - process and goal. But here two answers:
- Let FileMaker work as a robot. Open FileMaker Pro and use set a timer to schedule your script.
- You can let FileMaker test for the presence of a new xml file to parse and then the script will run and do what it has to do.
Instead of being concerned about how to force quit FileMaker you would probably use something like keep it up or some other method to ensure that FileMaker is started correctly if you should restart the computer and that it is always running.
B - if you for some reason want FileMaker to be closed in between sessions
- Just let the last scriptstep close FileMaker and forget about letting the applescript do this.
Then you can let your applescript start the solution and then the solution will quit when it is finished. This way you are also sure about the state of files, flags in the OS/file system etc.
Force Quit is a measure to be used when things go wrong. Not a production method.
This is absolutely a more house trained behaviour and you will avoid damaging your FileMaker file (scripts, TO's etc) by crashing all the time.
The two scriptsteps that may or may not make the difference for you:
I was afraid that this is where the discussion would lead. I am familiar with Filemaker. I was trying to find a simple answer not a debate. I won't take your answer as being rude since it follows the path of every discussion I read on other forums.
The bottomline is that due to issues most likely related to a plugin in the solution that provides the FTP function, the solution will freeze. Literally freeze. It becomes totally unresponsive. If it's unresponsive you can't use and scripts or triggers within Filemaker to fix the problem. An app that is frozen can't fix itself. You can try every Quit command you want and it will not quit, via menu, via Applescript, via the Task Bar. I could spend about $1,000 in dev funds with the plugin's developer to track down the possible issue (which is probably caused by the instability of my local internet provider). Or I could, as I did the in the past, walk by every few hours and see if it was hung. If it was hung, Force Quit, which in fact 50% of the time corrupted the file and I would have to replace it.
(The plugin is a custom plugin that does a ton of speciality stuff. So changing plugins is not an option. I can live with this flaw if the answer is to use 4 other plugins and especially when the problem is probably caused by Com....my interner provider. )
This can occur once every 6 weeks or every 15 minutes (it usually happens every 2 weeks but Murphy's Law rules here. It will only hang when I'm just sitting down to dinner at a nice restaurant with my wife on a Saturday night or in the middle of a movie.
This solution processes hundreds of stories and photos a day and simply has to run with a downtown time of about an hour being acceptable.
Force Quit is the only way to fix the immediate problem without spending a lot of time and money. The Applescript App using the Force Quit method on the Runtime solution has worked flawlessly for 6 months. I've been running the solution for the client and they are now ready to bring it in house. The client has been using Filemaker for years wants to run it under Filemaker natively so he can quickly edit the solution if he so chooses (He could simply edit the USR file but I don't want to prolong this discussion any more than necessary).
So, the question is how do I force quit Filemaker. Nothing more.
Daniel Doughtie wrote:
So, the question is how do I force quit Filemaker. Nothing more.
I don't have an answer for you - after all, it's not really a Filemaker question. I've noticed someone else (?) asking a very similar question on another forum - also with no reply.
Perhaps you should consider an alternative to your plugin, esp. since you are running AppleScript anyway. AppleScript can call cURL to download a XML document from an FTP server. Filemaker can import an XML document natively, using a suitable XSLT stylesheet. The same applies in the opposite direction, so the question is what is the remaining "ton of speciality stuff" that the plugin needs to do.
We could probably have avoided this if you had written that your problem was
related to a plugin in the solution that provides the FTP function, the solution will freeze
OK. If you dont want to solve the problem by using another, better, plugin, then you should consider go for a solution like Keep It Up which will monitor your mac and the indivdual applications. It will even restart your FileMaker if needed and let your startupscript make sure that the robot is working.
You do not mention which version of FileMaker and which version of Mac OS X and which plugin/version. This will keep the advices you get pretty general.
But I am pretty sure that Keep It Up will do what you need.
Only: I am also sure that using crashing solutions* is probably no good strategy if what you are doing is important in a workflow and for users/customers.
*We are using FileMaker driven robots and FileMaker Server Scripts. We are having at least 20 robots running year after year for customers. Since FileMaker 8 or 9 they have been very stable and if running in a stable environment they will run, run, run. Problems we have found has been related to less than optimal configured virtual envirionments, specific errors that could be solved, plugins with memory leaks etc. And our experience is that when a plugin has a problem, the developer will usually be extreemely interested in solving the problem.
Unfortunately the client is part developer of the plugin so he has a vested interest. And despite this one flaw, if it is indeed the plugin's fault, it's a really cool plugin. Until I figure something out my current answer will be to keep it as a Runtime and let him edit the USR file when necessary. (By the way to anyone else who might need it Do shell script "killall Runtime" works really well.)
In a perfect environment I would totally agree with your assessment. Unfortunately I'm not in the perfect environment and living within the rules of the client (not sure if you saw the above reply---the client is part-developer on the plugin). I've also have many robot solutions that run with no problems and on Server etc. I got one solution with one problem. Simpliest fix is sometimes the most expediate and cost effective. (On the tech side it has run on OS 10.4.8., 10.5, 10.6, and 10.7. On FMP 10 and 11). I should have provided more info but then again I was looking for a simple answer to a simple question. If it can't be done then the answer is "no."
Thanks for the lively debate.
on 2012-03-16 21:45 Daniel Doughtie wrote
I want to force quit Filemaker within an Applescript.[ ... ]
2. Almost all apps can be force quit in OS 10 with do shell script "killall AppName". (in the case of the run time its do shell script "killall Runtime"). Works with just about any app, except Filemaker.
killall by default sends a "TERM" signal; in my experience a "KILL" signal is
more absolute, and works better with hung processes; i habitually do this with
"kill -9 #" (where # is the process number) but i think "killall -KILL name"
does the same (where "name" is the process name, which may be different from
the app name)
and this is assuming your AppleScript runs from the same login session as that
FileMaker process, if not, you'll need to use sudo and authorize it
when kill -9 doesn't work, that usually indicates the app is in some sort of
i/o wait such as for a bad disk or (relevant to your situation) a failing
network operation; since this is related to a plug-in, there could also be a
race condition in an interruptible part of the plug-in code
And if killall runtime or other commands does not work - or if the controll of them (and when to run them) and the consequenses of using them are to complicated - You should definetely try Keep It Up ... it is what I would call a simple answer:-)