For most folks this is not really of much practical value. It pretty much boils down to the story of some FMP monkeying around that I've been doing in the last couple of days which I find interesting enough to want to share. If your time is limited, and fringe FM experimentation is not your thing, I suggest that you don't take the time to read this post. For anyone else, I hope you enjoy.
I wanted to experiment and see what "alternative" options there might be for using FMGo~iPad and AppleScript to control my desktop OSX machine and the instance of FMP running in that (desktop) environment. I wanted to be able to do this in both FM versions 11 and 12. The obvious routes that I knew of meant employing something to listen on a port on my desktop machine, and have that listener respond to an HTTP request generated from FMGo (using a webviewer, or something similar).
Certainly there are some plugins available which would do exactly this: listen on a port, and then trigger an FM script which could in turn optionally trigger an AppleScript. H0nza has got such a plugin, so does 360Works, and I'm sure there are others as well. Moreover, I was considering writing a small amount of Java to run on my desktop machine to do this port-listening job.
From my iPad via FMGo, I wanted to have access to things that only the desktop machine would have. After reading all of the posts to the Forum thread on improvements to the Relationship Graph, I though it would be cool to dust off a dashboard widget I once wrote which used AppleScript to help me browse lists of Table Occurrences in all open FM files, and navigate to individual TOs via Universal Access. But this time, I wanted to leave widget development behind and instead do my browsing from the iPad. The thought struck me as super cool: Have my iPad sitting on the desk as I develop, and be able to browse lists of TOs and relationships from a touch screen, and then be able to touch what I wanted to go to, and have my desktop machine respond accordingly. It seemed like a good weekend project -- the only piece that I needed to develop was sending the command from FMGo to my desktop machine.
Then I added another constraint:
I really wanted to see if I could do this without having to open up an additional port in the firewall for my "trigger" communication to come through. My thought was that if what I created turned out to be really useful and I wanted to share it with people, I didn't want to have to ask them to open up extra firewall ports, especially to allow traffic to a Java application.
Truncated version of the story:
I did not succeed given the above constraints, but I came rather close and had a fun and interesting ride.
Update: It's now starting to look like I may be much nearer to success than I thought.
* * * * * * * * * * * * * * * * * * * *
Longer version of the story:
I've never used plugins much. About a month ago, however, I really enjoyed using ScriptMaster to invoke an FM script via the calculation engine. This ability definitely seemed like an opening to what I wanted to do -- the only quandary being that we don't use plugins with FMGo. Yet: If I was willing to host my file as peer-to-peer from the desktop machine, with FMGo as a client, it seemed like there might be some way to leverage a plugin that the host machine has access to.
Here is the approach I took:
• I created a very simple table with only one record in it.
• In the table definition I included a single unstored calc field.
• The unstored calculation always returned a value of 1, but I nonetheless defined it to be unstored.
• This field used a Let() function, and within the Let body, I experimented with references to external functions from plugins installed on the host.
• I played with functions from both Goya's BE plugin, as well as 360Works' ScriptMaster.
With some experimentation, I discovered that it certainly is possible to invoke some Host plugin functionality from the FMGo client. Specifically, I did this via initiating a Find request on my one record table.
This allowed me to launch FM scripts from the iPad, which would run from the context of the FM host, thus allowing me access to much/most FMPro functionality typically unavailable on FMGo.
What I found however, was that, in order for this to work, I needed to queue up the script to run after some minimal delay (instead of using the plugin to invoke the script immediately). It turns out that this approach results in a very inconsistent delay for the script to run -- not something that you could really turn into a smooth process that a user would tolerate.
So I modified my approach:
Instead of using the functionality to queue up a script, I used the ExecuteShellScript functionality. My sense was that the inconsistent delay that I experienced with queuing up a script was probably due to simply waiting for FM to be idle enough to run the script. With this in mind, I figured that if I used the ExecuteShellScript functionality without any delay, I could use it to invoke osascript to run an AppleScript. My hope was that by handing off the task to command line and then from there to AppleScript, that I would gain some extra layers of independence from FM, which would allow me to execute AppleScripts with greater reliability.
This led to really exciting moments where I was running AppleScripts on my desktop machine which were initiated from my iPad via FMGo. I was only doing simple things like moving my web browser to the foreground, or getting a directory listing, or triggering a simple FM script that just showed a dialog. Nonetheless, the thoughts of what sort of FM Desktop/iPad integration UI possibilities this could open up were really tantalizing.
Where things started to crumble:
Even though this second approach of using the shell commands was much snappier than my original approach of queuing scripts with the plugin, there would still be these occasional moments where FM would just stall as it was processing the Find request for the one record with the unstored calc. This was not reliably reproducible, but it was definitely sporadically reproducible. My conclusion is that, as close as I seemed to be to success, I was seeing signs that I was getting into trouble for pushing the envelope more than it can safely be pushed. But I have to tell, you -- it was real cool while it lasted. It's not about the functionality itself -- as I mentioned already, I was aware that there are standard means for doing this sort of thing, but the thought of doing it all from within FileMaker -- no extra open ports beyond the standard FM networking ports, the only thing extra would have been the use of a single plugin -- that thought struck me as worth going for.
Update: Things are starting to work as desired. I believe that my inexperience/unfamiliarity with the plugins led me to believe that I was invoking them in the optimum/best fashion -- but I don't think that I was. Some further reading and further experimentation has led me to change (improve?) my approach slightly for using the plugins, and now I'm no longer getting the sporadic stalling symptom. If I get it working really well, I'll cook up a demo and post it. It is a lot of fun once it starts working.
That's pretty much it:
Thanks for reading & thanks to all the great people who post here. I learn lots from you folks each day.