October 3, 200322 yr 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?
October 4, 200322 yr 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.
October 6, 200322 yr Author 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.
October 7, 200322 yr 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.
October 7, 200322 yr Author 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.
October 8, 200322 yr "... 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).
October 8, 200322 yr Author 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?
October 8, 200322 yr 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.
October 8, 200322 yr Author Nope. No fields at all. The opener has no fields, just the one script that won't run.
October 9, 200322 yr 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?
October 9, 200322 yr Author 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.
October 9, 200322 yr Author 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.
October 9, 200322 yr 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?
October 9, 200322 yr Author 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.
October 9, 200322 yr 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.
October 10, 200322 yr 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
October 10, 200322 yr Author 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
October 10, 200322 yr 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.
October 10, 200322 yr Author 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)
October 10, 200322 yr 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.
Create an account or sign in to comment