Run script from fmp7:// call?

[kfutter]

I'm building a web-based intranet portal that will include the ability to open FileMaker databases using the fmp7 scheme (fmp7://serverIP/database).

Is there anyway to trigger a script on the target database via this mechanism? On the current FM-based portal, I have a couple of buttons that take users to different parts of the same database, and I'd like to replicate that functionality from the web-based one if at all possible.

Thanks in advance,

Kevin

Edited May 31, 2010 by Guest

[kfutter]

Nobody?

Kev

[kfutter]

OK, I guess that's a 'no' then...

Kev

[Vaughan]

I'd like to replicate that functionality from the web-based one if at all possible.

If it's a web-fronted database then the fmp7:// url isn't applicable.

Is it IWP or CWP?

If IWP, put a conditional in the startup script that tests get( applicationversion ) for the web client and changes to the appropriate layout.

[kfutter]

It's a standard web page, with buttons that open FileMaker databases using the fmp7:// scheme. What I want to do is run a script from that call, but I'm pretty sure it can't be done.

I basically have a database that I'd like to provide multiple buttons for, each one taking the user to a different layout in the database. When the front end was itself a FileMaker database this was simple enough through triggering a script. Not so from a URL it seems.

Kev

Edited June 24, 2010 by Guest

[Vaughan]

It's a standard web page, with buttons that open FileMaker databases using the fmp7:// scheme.

Ok, but are you using IWP or CWP?

Don't program the buttons to open the databases. Program them to run the script in the database that changes to the layout.

[kfutter]

Sorry Vaughn, you're not understanding me. I'm not running either IWP or CWP for this. It's a standard web page that isn't drawing any information from FileMaker (no web publishing involved on the page in question). It just has some form buttons with fmp7:// URLs attached. Clicking these finds and opens the required database, from the server, in the user's local FileMaker client.

What I would like to do is something like a standard GET request:

fmp7:///?script=

Like I said, I don't believe it's possible, but I'd like to be wrong.

I'm aware of all the other stuff, as it's how we've been doing it up to now. We're moving away from having a local 'portal' file on client machines, to doing it from a central location (part of our Intranet).

I know you're going to suggest hosting a portal database on the server, and publishing it via IWP (which is I suspect what you erroneously think I'm already trying to do), but I'm just not going there.

Kev

Edited June 25, 2010 by Guest

[Vaughan]

Ok got you on the web page. You're right, I didn't get you on that at all. My bad. (It might be quicker to draw a picture for me next time. LOL)

AFAIK the fp7 url format does not allow for specifying scripts or layouts.

If the functionality is mission-critical, build little opener files for each database/layout and host these on the server, then reference these in the url.

[kfutter]

Ok got you on the web page. You're right, I didn't get you on that at all. My bad. (It might be quicker to draw a picture for me next time. LOL)

AFAIK the fp7 url format does not allow for specifying scripts or layouts.

If the functionality is mission-critical, build little opener files for each database/layout and host these on the server, then reference these in the url.

Thanks Vaughn, you've confirmed my suspicions. Your workaround isn't a bad idea actually, but a bit clunky for non-mission critical stuff. Still, I'll file it away upstairs and see how it goes.

Thanks for you help!

Kev

[Drew Wesley]

A new FMP7Script protocol that launches a url-defined script is available for FM Go.

"Opening files using the fmp7 script protocol with FileMaker Go"

http://help.filemaker.com/app/answers/detail/a_id/7786/~/opening-files-using-the-fmp7-script-protocol-with-filemaker-go

Syntax:

FMP7Script://192.168.10.0/Client.fp7?script=ListClients&param=TopClients&$NumberToList=10

I've been running some tests on a Windows machine to register this protocol for use on a desktop environment.

[color:gray]---

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOTFMP7Script]

@="URL:FMP7Script Protocol"

"URL Protocol"=""

[HKEY_CLASSES_ROOTFMP7Scriptshellopencommand]

@="C:Program FilesFileMakerFileMaker Pro 11 AdvancedFileMaker Pro Advanced.exe %1"

---

Results so far:

• I can partially register the protocol so my shortcut shows the FMP icon and calls the application, but get an error when using the %1 suffix in the registry:
  'The file "t://192.168.10.0/Client.fp7" could not be opened. (Not Found)'
  
• Changing the %1 suffix to a %2 (or any other single-digit number) doesn't produce the error and calls the application : , but also doesn't prompts for authentication. :
  

I don't understand why FileMaker, Inc. released the upgraded protocol for their FM Go "mobile app" before the FMP desktop versions. A silver lining is that there doesn't seem to be any server requirements.

[DanShockley]

If the clients are using Macs, you could build a little AppleScript application they each have that registers your own custom protocol (e.g. kfutterlink:// ).

Then, the AppleScript checks the incoming link and if it meets certain criteria (begins with kfutterlink://, for example), opens up the correct database by scripting FileMaker Pro, puts the URL into a global field in that database, then tells a script in that database to run (and the script processes the URL to do whatever features you want available). The reason putting it in a global field is necessary is because AppleScript can run FileMaker scripts, but cannot pass parameters to them (probably a side-effect of the AppleScript dictionary not being kept up to date with "newer" FileMaker features).

Take a look at the following link to understand the protocol part:

http://applescript.tv/linktrigger/

Not everything in that article is needed for what you want to accomplish, but it explains how to make an AppleScript applet that is launched when a custom URL is clicked (from within any other program). I've built something like this for our system, along with it handling a custom file extension so we can double-click attachments that are actually FM database files with a custom file extension, watch as the AppleScript applet opens and processes the database in some fashion (running a script in another database that imports it, and so on).

I'm following this topic - let me know if you'd like to know more. I may be putting together a how-to on this in the next month or two, either way.

Of course, this technique is Mac-only, although I suspect there may be something like it for Windows, even if it involves requiring to build a more traditionally-developed application than the low-barrier-to-entry AppleScript provides.

[kfutter]

Thanks for your replies guys. I didn't receive any notifications of them, hence my very tardy response! This problem was solved for me long ago by using Vaughn's suggestion of using tiny opener files that then run a script to give me the result I want (in my case, either opening the database in a specific layout, or triggering the "open remote" dialogue).

It works, and usually pretty well, but I'm intrigued by the other ideas presented by Andrew and Dan. One of the major pitfalls of the approach I'm using is the limited (and decreasing) browser support for inline HTTP authentication (eg http://username:[email protected]). It works fine in Safari and Firefox, but Chrome re-encodes the @ symbol and any + characters representing spaces in the database name, which causes the process to fail. Apparently IE no longer supports this technique at all. Also, if for some reason the database call fails, the user can be left with their username and password dangling in the brower's address bar. Generally not a good thing!

Kev

[Vaughan]

"One of the major pitfalls of the approach I'm using is the limited (and decreasing) browser support for inline HTTP authentication (eg http://username:[email protected])."

You think that sending user credentials across the internet in clear text is a good idea, and that discouraging it is a bad idea? Having it dangling in the address bar is the least of your problems. :D

[jageo]

I know this is an older topic, but I came upon it through a search and thought to add my latest results after toying with this idea this afternoon.

Am working with FMP12.0v2, and can run script including passing variable values via the URL

There were several times it pooped out and didn't tell me what went wrong, but I did eventually, repeatedly, successfully launch and run remote DBs on my local network using the structure like this:

fmp://username:password@ 192.168.10.0 /databaseName?script=scriptName&$variableName=x

I read and used mostly what was found here:

http://help.filemake.../7786/related/1

but made what I presumed were logical changes based on using FMP12 and not FMPGo

The only bit I couldn't get to work was including "param=TopClients&" but I wasn't trying very hard once I had $variable working. I think I had something wrong in my script instead. I presume it would have worked as presented in the FMGO documentation if I pursued it further

JA

[kfutter]

"One of the major pitfalls of the approach I'm using is the limited (and decreasing) browser support for inline HTTP authentication (eg http://username:[email protected])."

You think that sending user credentials across the internet in clear text is a good idea, and that discouraging it is a bad idea? Having it dangling in the address bar is the least of your problems.

Hi Vaughn,

There's no Internet access to this feature, except via encrypted VPN. I wouldn't even contemplate it if there was! It's only available on an internal network that's been segregated into vlans.

Once FM fix their XML output bug for portal data using the FMPXMLRESULT grammar, we'll be able to upgrade to FM12 and take advantage of the new URL syntax for calling scripts. It still won't solve the http authentication issue, but I can live with that under our current set up.

Kev