I can't find the topic of my question

[Asu]

hi,

I am returning to using FMP after 3 years, jumped from v6 to v8.

Sorry, I have a general question and I can't find the section for it. I keep it short here: is there a way to intercept a user initiated close window or quit app action (via menu or window bar)? Thanks

[Kent Searight]

What exactly do you want to do? Run a script if someone Quits or Exits FileMaker?

[Asu]

Not really. I want to abort the action and let the user quit only via a specific button being pressed.

Any suggestions?

Edited March 29, 2006 by Guest

[Kent Searight]

Try the script steps:

Allow User Abort [Off]

Pause/Resum Script [indefinitely]

This will do what you want but you'll pay the price by having to make your solution totally script driven because while the script is in its paused state, most menu items won't be enabled. This can also add a level of complexity to halting scripts from their subscripts.

If you're concerned that something isn't going to be set properly before a user quits, you might consider using an exit script to check for errors before shutting down instead of the above method.

Hope this helps!

[Asu]

So it seems that there is no way to abort the closing of a window once it is initiated. It is an interesting solution though, thanks.

[aaa]

Hi, Asu!

If it is necessary to me i do it such-as in attachment.

Open_New_Window_And_Close.zip

[Kent Searight]

I'm curious...why put the Pause/Resume Script [ ] step in a Loop?

[Fitch]

Another option available with FileMaker 8 Advanced is to use custom menus, then you can make the Close and Quit commands do whatever you like.

[LaRetta]

From what I understand, Tom, you lucky Mac Users don't have an application windows bar (widgets). It sucks because Users can escape too easily (and it wastes layout space). There are plugins available ... I use SecureFM with Menu Magic. There was another program I used for vs. 6 called Windows Utility, I believe (I could hunt it up if you like). But I don't know if it works with vs. 7 or 8. And there are probably other plugins available which also remove/lock the windows widgets.

Where's SteveInVegas? He tightly controls his solutions as well and I think he might use Dacons? Anyway, there are some options ...

[aaa]

Hi, Kent_S!

If it is not in Loop user once can press on "continue" button on the Status area, then close window with [x] on top right angle on it.

[LaRetta]

The problem of course, aaa, is that on Windows you can still exit the APPLICATION by the windows widget X, thus closing the file. You can stop the exit of additional windows by freezing them (and I've done that also), but not the application itself. Freezing a window doesn't keep a User in your command because, when they see THAT window's X won't get them out, they'll just reach up and close the whole app instead. It provides a false sense of security only ...

[Vaughan]

There was a tip posted to the FSA list a few months ago that described a technique that used field-level validation to prevent window closure.

Make a field in the table that is validated NOT to be empty. Leave the field empty, then when users try to close the window the validation will stop them (give the validation a descriptive custom message). In your window close script, put a valur into the field and it'll let the window close.

[aaa]

It is good if we dont want do anything on the window, but if we want to edit any field i think validation will dont let to edit.

[Kent Searight]

Hi, Kent_S!

If it is not in Loop user once can press on "continue" button on the Status area, then close window with [x] on top right angle on it.

Ah yeah, that totally makes sense. I lock out the status bar in my solutions so I hadn't considered that.

Thanks!

[Kent Searight]

...when they see THAT window's X won't get them out, they'll just reach up and close the whole app instead. It provides a false sense of security only ...

Hi LaRetta,

I'm assuming that the main concern of Asu is to stop a user from exiting FM before something has been completed. Can you think of an example in which a shutdown script couldn't act as a last line of defense against this?

[LaRetta]

Hi Kent,

I hope I learn a lot from this - thank you. I haven't tried the field validation technique. I started to put together a file but I have nothing to put in it. No matter what I've put in a shutdown script, if the User clicks the FM application windows X, it closes.

Here's what I started:

Create a global (number) gNoQuit. Startup prefills with 1 - meaning they can't exit FM until that is a 0. Startup script is simple Set Field [ gNoQuit ; 1 ]. Even attaching both of the scripts in File Options, what would a Shutdown script look like? I began with:

If [ gNoQuit ; what ? ]

Open file again? Open it back on the Main Menu, I suppose. But an exiting script will not open itself again. Please, oh please, tell me I've been wrong. It would make my week ...

BTW, I only interjected because of the application X. I can freeze windows with loop/pause (or SecureFM), just not the application shutdown.

UPDATE: I realize I can write the errors - but I want to STOP the shutdown.

L

Edited April 3, 2006 by Guest
Added Update

[Kent Searight]

Hi LaRetta,

I don't think I articulated my question very well.

Since it does seem that if a user is determined to quit the application, then that is what will likely happen eventually. My question to you was whether you could think of an example in which a closing script wouldn't at least put data in a state that could be dealt with when the file is opened again. That's why I referred to it as a "last line of defense", i.e. when all efforts fail to stop the user from following the rules.

Maybe my question reflects my belief that if there's a way for a user to do something they're not supposed to do AND there's no sure-fire way of thwarting it, then a backup plan has to address the possibility of this happening.

[LaRetta]

"Can you think of an example in which a shutdown script couldn't act as a last line of defense against this?"

Well this got me darned excited, Kent. I thought maybe vs. 8 had new tricks to use to stop application close.

"Maybe my question reflects my belief that if there's a way for a user to do something they're not supposed to do AND there's no sure-fire way of thwarting it, then a backup plan has to address the possibility of this happening."

I'm in total agreement. I would estimate that 15% of my solution is geared towards lock-down, error check and tracking User work. But I don't use Shutdown script to handle it because there are 50 tables in which a User might have left something unfinished. Instead, each table uses Auto-Enter (Replace) flags to track that everything is done within each record AND I have WorkToDo table for assigning other tasks (which overlap tables or processes). Then, upon opening the solution, each User is presented with THEIR page which has portals of their invoices unfinished (those flags), calls to make, work to do, their commissions to-date etc. MY page shows ALL work undone; Sales Manager page shows Sales work not done etc.

My theory is that, to be sure everything is done completely, it must be placed in front of their faces AND all staff knows their work is timestamped so each time they are late, Management knows. And each time Orders are shipped but one of their orders can't ship because they dropped the ball, an Error is assessed against them. Repeated errors or patterns are discussed with the staff.

If a User must be held in place, ie, MUST verify ship address with Client (while on the phone), I loop/pause the window and won't let them out. Otherwise they are free to leave - BUT right above the CLOSE button on every layout is a list in RED of unfinished items from that process (TO).

I provide reminders, help, warning messages, error flags ... then it ends up on the Manager's view. Critical overdue lands in the Owners portal and that's very very bad. It rarely reaches that point. :wink2:

[Kent Searight]

Hmmm, I really like your approach with auto-enter calc flags and keeping the data in front of the user. I'm working on something now in which that would be the perfect solution.

As usual, LaRetta, thanks for sharing the wealth :D

[Vaughan]

One other trick I've heard of for preventing a solution from being closed is to get the shutdown script to open a new window! This won't prevent the application from being closed.

I just made a simple test file, and indeed opening a new window stops the file from closing. It also stops the application from closing and goes into an infinite loop, urrgh. This could be worked around with some fancy scripting though it'd mean having to create an application close script and teaching the user to use it instead of the menus: I could see this getting really ugly.

I seem to remember now that the shutdown script put up a "Do you want to close the solution?" custom dialog and used the new window trick as a way to stop the solution from closing (since there is no way to stop the window from closing).

[LaRetta]

Windows Users are so ingrained to hit the top-right corner to close app (that X). I even put my close button right below it in 18 pt. RED and they STILL hit the X instead. Next, I'm going to put masking tape over the top right 2" of their monitors (completely covering it). I have other ways to catch errors but I want total control (short of kiosk).

This is certainly worth playing with. Thank you, Vaughan! I adore things such as this ... oh, and placing a window totally offstage - how cool, thanks ThatOneGuy!

L

[Fitch]

I'll have to test this, but my understanding of custom menus is that they can take over from equivalent widgets (clicking close box etc). So a script assigned to a custom Quit menu should work.