1 of 1 people found this helpful
360Works RemoteScripter can trigger a script on the remote client when the value of a field changes.
on 2013-06-13 15:42 Hudi wrote
So, instead of running the script all day looking for that flag field, I was wondering if users in the same office and network could execute the script on the robot without having to keep the ontimer script running every 2 minutes looking for that flag field. Can they perhaps execute applescript?
yes, AppleScript supports Remote Apple Events; you have to allow it on the
destination machine (System Preferences > Sharing); then on the source machine
run something like this:
tell application "FileMaker Pro" of machine "eppc://namefromsharingprefpane.local" tell document "name of your document" do script "name of your script" end tell end tell
triggering a script like this could be trouble if there is an active FMP user
at the remote end
if you have only allowed specific users Remote Apple Events access (a good
safeguard), you'll need to add a user/password to the machine string
the above should run as a Perform AppleScript script step; to run in
AppleScript Editor you may have to wrap in "using terms from..."
I was watching this thread to see if those more familiar with ODBC Imports would ask why you're not running them server-side? I believe it is possible, as long as the DNS are named correctly.Then you can have a server script watch the flag field.
Unfortunately, odbc imports can only be done from the client. What can be done, and I may need to consider this, is importing from a table occurance that is an ESS.
You raise a good question and it really is a shame that we can't do this.
Where I learned this: https://fmdev.filemaker.com/message/117840#117840
on 2013-06-14 11:51 Hudi wrote
I tried a few variations of what you suggested.
Running into issues though.
Also, if its a hosted file, does the server need to have sharing activated?
i doubt it, but have not tried it; let us know what you conclude
Here is what the script looks like
i haven't done remote events in years, but when i google the error message it
suggests a user name password issue; it is possible that you could put in just
the user name, and it will ask the password the first time, offering to save it
in the keychain; this would be more secure than coding the password into the
tell application "FileMaker Pro" of machine "eppc://user@L2-Conferences-Mac-mini.local"
beyond that, i think the proper document reference would be
tell document "Start.fmp12"
(no path, the database file must be open)
This contradicts FM KB Article 7035, which states that ODBC imports are supported server-side.
Well, I'll be a monkey's uncle ...
I just tested server-side ODBC imports. The KB article is correct. You can do this, as long as the identical DSNs are installed on both client and server.
Note: For the Import Record script step, 32-bit DSNs / drivers are required on Windows, while 64-bit drivers are required for ESS. (Ran into that one some time back.)
Will cross-post this to the other thread to make sure we don't have bad info floating around.
1 of 1 people found this helpful
if you want to tell the robot to do something from a remote client delete a record which is open in a window on the robot. when the next record loads an OnRecordLoad trigger fires and you can take it from there ..
just watch that the window never closes and the record you can aim at from the remote client is known to the robot and the current record and the other client knows it's ID ..
good luck ..
(it requires at least fm10 ..)
I like that. Using script triggers.
I was using that to open the remote file on the robot (ical event script opens a local dummy database which triggers a script the openning of the remote database)
Had not thought to use them to trigger the import script.
it's actually THEE solution - you can even create records on the robot for each potential client and it also works on FM GO ..
no plugins etc .. and you just recreate the record when it's deleted to get the record back and refire ..
so the problem should be solved!
It's great. so simple.
Question: why 'delete'? why not go to next record or anything else that will trigger the script (OnRecordLoad, OnLayoutEnter). Its a small thing but I'm just curious if that's the only way to make it work.
it has to be passively aggressive: only deleting the so call triggerTheRobot record from the remote client will if it this same record is open in a window as the current record ignite the OnRecordLoad trigger thru it's disappearance there.
the onRecordLoad trigger will recreate that record for the next run and now do all the desired work you have planned for the robot to do when the event occurs ..
on 2013-06-19 10:05 FileKraft wrote
if you want to tell the robot to do something from a remote client delete a record which is open in a window on the robot.
interesting but abstruse; i have used the model of creating job records which
the robot keeps watch for in a loop; this is not as purely event driven, but it
gives you flexibility to send parameters, trigger multiple types of tasks,
etc.; and the client(s) can queue up multiple job records without worrying
about handling a second event trigger before the first job is finished