Opening a db from a desktop icon

[DonH]

Okay, I now have a script that connects the client to the server and opens the application.

What I tried doing was putting that DB on the desktop so when clicked on it opens FMP and then should open the db and run the script. Seems logical. But it doesn't work.

I looked all thru the manuals for how to do this and the only answer is to use the SDK and bind all the files, which I don't want to do.

So how can I make an icon on the desktop that will open and run a script?

[Fenton]

A FileMaker file on a client desktop can use the Open Remote menu command or script step to "open" a file that is already open on a "server" machine, ie., is already hosted by either FMP Server or regular FMP on that "server" machine.

It cannot Open a file on another machine that is not already open on that machine. The words "open" and "server" have more than one meaning, depending on the specific operation.

If everything is set up correctly, and you're using Mac OS X, it requires 2 double-clicks, one to open the FileMaker application (if not running), then another to open the file. Yeah, pain-in-the-butt, hopefully fixed someday.

[DonH]

I'm on Windows. What happens currently is that I double click on the db on the desktop and it opens FMP and then the db for editing. Doesn't run the script even tho I did the preferences saying to run the script when the file is opened.

[Vaughan]

What steps is the startup script using? The Open [] step does not reliably work for running scripts in external files: it only opens them. If the file is already open then it basically does nothing.

Instead, use the Perform Script [external] step to explicitly call the script in the external file. If the file isn't open FMP will open it then run the script. If the file is already open the FMP will run the script anyway. Reliable and robust.

[DonH]

Oh, that is no problem. The real problem is getting the initial script to run.

I have a file called CHARTSTART.fm3 No data just the script to open the file CHART.fm3 on the FMS.

CHARTSTART will sit on all the client machines and they only need to click on the icon on their desktop to get the whole ball of wax rolling.

Right now what happens is FMP opens and CHARTSTART opens minimized and does nothing.

So forget about running an external script for the moment, I think I have that down, but instead, how to get a script to run from a desktop icon.

[Vaughan]

"... just the script to open the file CHART.fm3 on the FMS."

You missed my point entirely. Don't try to open the file, use the Perform Script [external] step to explicitly call the script in the remote file. It works.

The opener file (that's what we call these small local files that open databases on FM hosts) should have a script in it with the Perform Script [external] step to explicitly call the script in the remote file that you want to run. Set this script to be the startup script (in the document preferences).

[DonH]

That is what I am doing. However, back to the problem, the opener file does not run automatically.

CHARTSTART is the opener. I took it and put it on the desktop. When I open it from the desktop, it opens FMP and then CHARTSTART sits minimized at the bottom of the window. The script that is set to run automatically on opening does not run. This, of course, means that a client could try editing etc.

So what am I doing wrong on the opener that it doesn't automatically run?

[-Queue-]

Does the opening layout have a related field to the file you're opening automatically? If so, get it off that layout! Files that open via relationships will not run their on open scripts.

[DonH]

Nope. No fields at all.

The opener has no fields, just the one script that won't run.

[-Queue-]

Can you attach it here?

[DonH]

I will try!

OBCHART2.txt

[Vaughan]

Does it have any records? It may need at least one record to function.

Could you at least show us the ssript steps you're using?

[DonH]

It should all be in the file I attached. If not I can put it up here. I'll have to try putting 1 record in it, see if that works.

[-Queue-]

Um, that's a text document. Can you zip the FM file and attach it?

[DonH]

Try this again

obchart.zip

[-Queue-]

Can we get the password?

[DonH]

Thought I took that out. Busy busy day today. Brain gone to lunch.

Password is admin:-)

Don't say anything, I didn't decide on that password.

[-Queue-]

Well, this one is definitely running its on open script. When it attempts to open the Chart.FM file, the TCP/IP box pops up, and when it fails to connect I receive the 'Contact the administrator' error. Is it the Chart.FM file that you think isn't running its on open script?

[DonH]

No, Chart works fine. The problem being that the 2nd time I try to run the OBCHART file it won't work. If I make a small change it will work. Then it won't after that.

[-Queue-]

Once the file has been opened, you need to close it if you want to run its on open script again, unless you execute the script via a button or external script call.

[stanley]

Don:

All I get is your error message. Also, the file is locked via a password, so nobody can see the script. Can you provide the user/pass or post another version?

Oops - I missed the second page of posts... yes, it runs its script.

-Stanley

[DonH]

Now where should the call to close the file be? CHART locks everything up and so putting the close in the opener script it doesn't run that step.

Anyway, I cheated. I have a RUNTIME app that opens CHART for another purpose and so I just modified it to stop after it does that. Of course that leaves me puzzling over why one runtime app will call CHART but another one won't. hmmmmmmm

[-Queue-]

You could put a Close[] step in CHART, but it will lose all hoooks to anything that should run afterward (meaning you'll probably end up with a zoomed or minimized opener file). You could put a step in CHART that calls an external script in the opener file that has Close [Chart] in it.

[DonH]

Ahhhh the OBVIOUS answer. LOL

Yes, a call back to the opener file.

Does 6.0 have the ability to refer to the calling file/script? If not, it would be a nice addition for security if nothing else (tho I can think of a LOT of uses for it)

[-Queue-]

I'm not sure, but I usually use globals for such a thing. If fileA, fileB, or fileC calls a script in fileD, I set a global in fileD to 1, 2, or 3, respectively, and use this to determine which steps to perform and which to ignore.

[-Queue-]

P.S. What the heck is a respons?