It can't work, as the fmp protocol is tied to the FileMaker software (and not a standalone runtime).
You could possibly change the protocol handler to your runtime through the OS (not sure if it would work the same or not), but that would direct ALL fmp links to your runtime.
Would you be willing to share any of the details of what the WebViewer renders, and how the user is expected to interact with it?
Also: Which platform(s) are you building the runtime for?
For what it's worth, I was able to redirect the FMP protocol to a runtime and have it trigger scripts. Like I said earlier, though, that will redirect for ALL FMP URL links on the system. However, when I attempt to use a custom protocol handler (tested with "FMRT" for FileMaker RunTime), the runtime will launch but the script does NOT trigger.
Changed FMP protocol using RCDefaultApp prefPane on Mac - pointed the protocol to the runtime file insteaad of FM 13.
Added an entry in the info.plist in the runtime app to designate FMRT as a URL Scheme for the App.
FMP://$/test?script=test¶m=12345 -- opens the runtime and runs the script -- success!
FMRT://$/test?script=test¶m=12345 -- opens the runtime but does NOT run the script -- FAIL
There may be something analyzing the link when it hits FM that is causing the custom scheme to fail. This is my first foray into custom URL schemes, so I could be missing an easy fix!
@PalmDBS: You are always posting great stuff, and this is a good case in point. I look forward to seeing if the custom protocol could work out and be made to trigger the script as well as launch the file.
@Ric & PalmDBS: As workarounds, below I'll list a few other options that perhaps would be worth considering.
1) Old-School OnTimer Approach
I am wondering if an "old-school" approach could work for this situation. "Old school" as in pre-FMP-URL-times when developers would use an OnTimer script step to watch for URL changes in the WebViewer. I was never greatly fond of the OnTimer approach, but I do believe that in some scenarios it has its rightful place, and perhaps this is such a case. IMO, whether or not this would be appropriate depends a lot on the UI and how it hangs together.
2) Single-Click UI OnObjectEnter Technique
Another option, in a scenario where the only interaction that the user must have is to click somewhere in the WebViewer (no scrolling, no filling in fields, nothing other than clicking a button or a link) is to utilize an OnObjectEnter script trigger attached to the WebViewer. The triggered script starts off with a pause for a fraction of a second -- just long enough for the click event to make its way into the WebViewer to trigger a link or a button, etc.. Then after the brief pause, the script checks for a modified URL in the WebViewer. I just so happened to be tinkering with this very idea tonight when I realized that it might apply to this post. I tried it with an OSX runtime built with FMPA 13.0v3 and it seems to work as desired. I don't know if it works on Windows, but I definitely think it is worth a try. The key thing as I see it, is that this techinque of using the script trigger requires that the only interaction that the user has with the WebViewer is just a single click to make some kind of selection. In cases where the user must scroll through a list, or otherwise interact with the WebViewer before clicking on their selection, this would not work.
3) Using a plugin that listens on a local port and triggers an FMP script from within the calculation engine:
It has been quite some time since I have investigated this type of option, but, as I recall, 24U Software offers a plugin which might work in this regard:
In #1 and #2 above, when I refer to watching/checking for a URL change, I am referring to using GetLayoutObjectAttribute( "source" ) of the WebViewer.
IIRC, this would require the following:
a) The original WebViewer URL is set to a local or hosted file, not a data URL
HTH and best regards to both of you,
Actually fmp protocol works in a runtime.
The problem is calling a fmp url from a webviewer in a runtime...
I tried with a very simple example: I put in a field a fmp url calling a script, then I made a runtime.
If I use open url step, the script is executed on the file itself, as expected.
If I enclose this url in a very plain html code and put it in a webviewer, it doesn't work in a runtime (it tries to open FileMaker and, since the file is opened by the runtime, I get an error message saying "Unable to open xxx file. Host is not availble or the file is not available on that host")
Thanks for the suggestions, Steve.
Unfortunately, in my case, none of them is adoptable: the webviewer object is quite elaborate and supports several events (that work flawlessly in Pro or in a hosted file).
Changing the code or the main behaviour is not an option, for me.
Thank you for your replies and for filling in some more details. I appreciate it.
It is true: If modifying the webviewer code is not an option, then none of my suggestions would be useful.
Very best regards,
I wonder what happens if I make some test on a machine with no FileMaker Pro installed.
If the protocol handler set automatically the runtime as default application, I have a workaround.
I'll try on a virtual machine and keep you posted.
Short answer: no.
If no FileMaker is present, the WV simply doesn't react.
on Windows, add registry
I think adding "mp:" or "p:" protocol with command f"%1" or fm"%1", both runtime and pro may work together.
Sadly I can't test not having FM13adv.
You've looped back to what my original reply was. The FMP URL doesn't work with the runtime. It launches FileMaker Pro. Changing the FMP protocol to point to the runtime DOES work on Mac, but i don't think you ever responded with your platform. The problem with changing the mapping is that if your end user actually has FileMaker installed, you will have broken the FMP URL function for all other applications by directing the protocol to your runtime.
This is why I was looking at using a custom protocol, but if you're unwilling to modify the webviewer code, then exploring this avenue is also of no use.
It works with the runtime. But not in a webviewer in a runtime, probably because a WV uses the system defined handler (and that explains why changing it the way you did make the runtime work).
But in my case is not a viable option, not even with a custom protocol (non only because it would break the FileMaker native version, but because it would be a nightmare to install and mantain).
I'll see if I can make it work with a plugin.
Thanks for your suggestion, anyway: your way could be useful in other circumstances.
Any progress on this, Ric?