A repost of a "template" opener file. This is in FMP 6 format. No password.

The script is well commented to explain how it works and where to edit it for your system.

Tested on Windows and MacOS FMP 5.5 and FMP 6.

GenericOpenerFileFMP6.zip

Is there any difference between using an opener file such as this and having a script in the application on the Host machine which is Opened Remote by the user on the local machine?

In case Vaughn's not around, I would say, no, and yes. No, it's not that different, because the Opener is calling a script in the remote file, more or less the same as if you used Open Remote, and the targeted file had that script as the "on open" script.

But yes, it's definitely different as far as the user interface and ease of use. All the user does is double-click the opener file. It then specifies what script to run in the proper remote file - with no user interaction, no trying to pick out the right file, no need for that remote file to have that script run "on open," no possible mistakes.

In 7, if you know the client's server machine's IP, you can set the path ahead of time in the File Reference, saving time and trouble.

It's been a while since this thread was started, but it just occurred to me that it OUGHT to be possible to call the Opener file as part of the Application startup, so that the users don't have to remember to do anything to double click the Opener file. Is this too obvious or is there a technical reason it wouldn't work?

Reason I ask is that I am about to deploy the FM7 version of the application. However I am developing on a machine which does not have a network. Otherwise I would test it myself. ;)

... it OUGHT to be possible to call the Opener file as part of the Application startup, so that the users don't have to remember to do anything to double click the Opener file.

Hi Patricia,

If your Users don't double-click the Opener file, what will they double-click? The Opener file is what Users select to open your solution itself. If your Opener was called as part of your File Options > Perform Script on open, I think it might create a perpetual loop which might blow some circuits!

LaRetta

I think I'm getting myself quite confused. My confustion is due to looking at an example opener file.

Questions that I have not expressed well are:

Where does the Opener file reside/execute? On the Host machine I presume? Then which usesrs invoke it? The clients? Would it make sense to have the Opener program launched when the Host machine starts?

If files are opened via an Opener file/script which closes the only window does that not also close all the files that it "opened"? In the sample code that I was working from, as soon as the files were opened the application shut down.

Confusion on this subject is quite understandable, Patricia. :

Opener should be on each client desktop. That's how they open their copy of the application. Opener calls a sub-script in your main file on host. It works wonderfully and eliminates all of this Open Remote rigamarole!

Many things about networking I don't understand yet, but we've been using an Opener for (something like) a year and it's never failed us yet.

Yes, you are correct about needing to select a window when your main file opens (as part of it's startup or sub-script). I didn't understand this (and it's still a bit confusing). Because otherwise, the app can be open but blank!!?? I thought Mac didn't have this problem but Windows sure does!! This 'making your new file have a window' is a bit out of my realm ... I just finally stumbled on a combination which worked. Because we use SecureFM (full menu lockdowns and windows handling) it was a bit complex and tricky! But it works. It's on my things I must thorougly understand but much lower on my list. :

LaRetta

My confusion gets worse ...

I had previously thought that the purpose of the "Opener" process was to establish which machine was the Host machine. As you can gather this is a new area for me. The user kept mumbling about if they didn't do this then they ended up being the Host. But I thought that the Host machine was determined by the first user to "Open" the application.

Another point of confusion ... which files am I trying to open? In my case, I have modified the existing application to separate the UI and data. When I "Open" the files am I opening the UI or the Data? I have set up a single UI file and it "Opens" all of the data files. Obviously I haven't yet established network file references. I will have to get that done when I deploy.

Back to the drawing board ... obviously. I wish I had a network to test this out.

Thanks ;)

Edited August 8, 200520 yr by Guest

God girl, you sound exactly like I did right before we networked (without Server). I wanted to test and understand it BEFORE the fact. Trust that it will work. And we both have so many wonderful people here to help us get through it! Hang in there. ;)

Okay Patricia. I'm going out on a limb. Please everyone correct me if wrong as I go. I can only tell you what I know and what worked. And I don't have time to be specific, I'm a bit behind, so this is just a generic walkthrough, but I so much sympathize with what you're feeling right now:

In Opener file (I used Vaughan's example from here), create File Reference to your solution sitting on your host system. Select FMNet, I think it's called, and enter the IP address. Host should have static IP. Make sure NO OS file sharing is on the host system. Then in Opener, change the script line to Perform Subscript [ Startup script, selecting your main solution on host). Vaughan had it pretty clear on what to do. Place the same copy of this Opener on everyone's desktop.

I don't password prompt Users in Opener. Main file will prompt when it opens. Now, when we networked, it would NOT open host solution automatically when sub-script was called. It's supposed to. So I had to always have someone open the host file first (using what I called a Host Opener). Hey. We do what we need to to get the job done sometimes. If someone forgot to open Host first, no prob. Opener would just close itself cleanly protecting itself from trashing its script line where it calls the sub-script.

So first staff in the office opened the host system then it wasn't touched again. Staff comes in, clicks their Opener (which opens the FM application locally), Opener finds the host at the static IP and executes the host sub-script. Now... if Opener displays a blank window (grey, no window) but appears to stay open, it isn't!! It has closed itself! Don't let this trip you up! You are no longer looking at the Opener but are now looking at the HOST SOLUTION!! It means the host has been found and is open but no window has been selected so it looks closed!!! Major caveat. So be sure your host startup selects a window!!

Be sure host is not on a server - it is it's own Server (and a very sweet server it is too). Once Opener has found it, all should work very well indeed. You being Mac, some of this may not even apply (the non-window issue is an example). Oh. And be sure to turn on Edit > Sharing in every file AND click a dumb checkbox called 'All Users.' Its default is No Users, I think. This threw me off also. Also, any auxiliary files would not open when called from the host even though they were in the same directory (and properly File Referenced) so I ended up opening them (hidden) during host startup script. I also turned off 'Open Remote' options.

I hate putting out hit-or-miss technique ... but I wanted you to envision what it will feel like for a networked solution (without Server) and how Opener works from a 'non-network newbie' perspective. This period of time for me was quite stressful and I wanted to put your mind at rest (just a bit). This post is NOT to be used for proper network implementation. It is just one gal to another in an attempt to help one person. Okay, everybody?

LaRetta

LaRetta,

Thanks for the very helpful description of the process. (BTW, although I am a Mac user, the application will deploy on Windows )

I have another question about networking that has been worrying me for some time. When I deploy the application will I need to change the File References? At present I have a main folder with 2 sub-folders ... one containing the data files and the other the UI file. The File References are relative to the UI application file.

When I move this to the Host machine, will the File References need to be defined relative to the Host machine or relative to the Guests (Users running the application.)?

And if it uses the relative file references, will I have to change them for Windows? An example: file:../Data files/ClientData.fp7

Thanks in advance for your patience with this networking newbie.

I worried about that also but the File References were fine. In fact, I was afraid to rename my main folder when I moved it and left it named the same! With Server Advanced that folder is now gone, thank God! Otherwise we'd be working in vs. 3.0 of our program but still have it in a Beta 1.1 directory! ROFLMFAO!! It seems FM looks where it is, ie keeps the same orientation.

But, Patricia, remember I can only tell you what happened in ONE instance ... mine. Windows needs to see an .fp7 extension and I don't think Macs do but this is bits and pieces I've picked up over time - not something I would bet MY solution on; so don't you either, okay?

By the time I had put this into effect, I had read over 50 threads from various forums, had read everything FM puts out ... and still was nervous as a cat. You will be too. Make the switch when nobody is around but try to have an IT person handy (I didn't have that luxary). And I had to disconnect some Windows firewall or something - don't ask me where it was - it was a Windows thing, not FM.

Now ... when we went to Server Advanced, it was another thing entirely! We were up and running in 10 minutes! And I finally was able to get rid of the Beta 1.1 directory. No more important questions to me on this thread, though. "In the valley of the blind, the one-eyed man is king." If I post on this thread anymore, it'll be with questions, okay? :

LaRetta

read this

Sorry Jimmy - can't see a link

Phil