Disable close/min-/maximize button under OSX

[Triodes]

Hi,

I'm running a multi-file for multi-user database with Server 8.0v3 on OSX. My users keep clicking the close button (x) which causes relationships to be lost, with all nasties that result from this. Is there a way to remove these buttons from the window? I'm talking about the red/yellow/green balls in the top left of the mac windows.

[Inky Phil]

You might consider invoking Kiosk mode as that is,I think, the only way to stop your user having access to and using those buttons.

Beware, it also takes away all native filemaker menus so all procedures and navigation have to be scripted.

Phil

[Triodes]

All functions/navigation is scripted, so that is not a problem. I will look into the kiosk mode right away.

Thanks...

[Inky Phil]

It should go without saying but try it on a COPY of your file first

Phil

[Tricky]

This maybe stating the obvious but do you not include a shutdown script in your solution?

I am not sure are talking about the terminate Filemaker button or the close file button, but when you ensure that all databases on closedown run a script, you can control what happens on closure, hence ensuring proper close down of all files and tables.

If you are referring to closing any dialog, make sure that the first option under the first 'answering' button is alwas the one with no impact (halt, or stop or whatever). Clicking the cross in a dialog is equal to clicking the default answering button.

Hope this helps!

[Steven H. Blackwell]

Actually the best way to manage this problem--and it can be a huge problem--is with teh Secure FM plugin from New Millennium.

http://www.newmillennium.com

Be aware that the Exposé function in OS X can also cause severe UI integrity issues for which there is at best only a limited workaround.

Steven

[Triodes]

I have an application running under OSX that contains about 43 files. Under OSX each file opens as a new window. Problem with this is the users want to go back to another screen/file and just click the little red ball with the X (close app). There are numerous relations so the place where the users closes a certain file causes problems with invoicing etc (now seeing a different customer and what not).

The option to add a shut-down script is an option, as I could force them to the main menu in order to rebuild the path they were working with.

NB: Yes, I would indeed use a copy to test these kinds of things on I don't think Kiosk mode will work, as all users need the ability to change value-lists, one of the criteria that disables kiosk mode according to the manual (yeah, actually read some of it).

[merlyn383]

I have an application running under OSX that contains about 43 files. Under OSX each file opens as a new window.

I have a similar database structure. My solution was to create a single master file. This master file contains no fields/data/etc. I referenced all of the other files and defined all the relationships in this file. Then I created all of the layouts in this master file as well. Granted, it's over a hunderd layouts, but since navigation is scripted the users never see that ugly dropdown.

This allows your users to work in one single window while still having access to all of the data in the 43 files. When this one window is closed all of the relationships are terminated.

[Søren Dyhr]

I think it falls back on your developement objectives and you willingness to embrace the new features, which I agree with David Kachel is a questionable practice:

before some of the folks on some of the FMP discussion lists starting claiming that separate files were “faster”, more stable, better this, better that... there are some people out there who are just not happy if they can’t put a hole in your balloon.

Well, separate files may be faster, I don’t know (and I don’t care), and they may be better this and better that, but they are also one other thing: dumb!

Don’t fall into this silly trap. FileMaker developers have been begging for single file FMP databases for years. They are wonderful, and a great boon to development. Don’t let yourself be bullied into doing things the old-fashioned way for nothing. If you can at all avoid using the multiple file approach, do so.

This means that the use of many windows can be avoided entirely, never use the new window features, but do instead get the max out of Custom Dialogs by using advanced wrapper techniques in your scripting:

http://www.filemakermagazine.com/modules.php?op=modload&name=News&file=article&sid=622&mode=thread&order=0&thold=0

Yet another option is to exploit tooltips better!

--sd

[Ender]

Soren, you should know better than to grab quotes from random places without giving the source.

You say not to use multiple windows, but that is an entirely different issue than using multiple files, which is what that quote is about. I'd have some arguments with the unsupported claims in that quote, but since it doesn't seem to apply and David is not here to defend it, I think we can skip it.

For Triodes, if a plug-in isn't desirable and rewriting the interface in a single file isn't an immediate option, the problem can be mitigated by switching to a blank layout and hiding the window as navigation proceeds to another file. With the other files only accessible via the navigation buttons, users will learn not to close the windows.

[Søren Dyhr]

You say not to use multiple windows, but that is an entirely different issue than using multiple files, which is what that quote is about. I'd have some arguments with the unsupported claims in that quote, but since it doesn't seem to apply and David is not here to defend it, I think we can skip it.

Yes I should know better! - than quoting without reference - here it comes:

http://www.foundationdbs.com/Downloads/WhitePaperForFMPNovices.pdf

What I'm trying to pass thru here is that, only partly done migration is to blame here. If multiple windows makes relations corrupt, when users accidentally toggles them off - and user might do so if they can be seen! Is a consequence of multiple files carrying the various layouts, I suggests one window for the entire commerce, to prevent the solution ad hoc opening files as a consequence of the dealings with the data.

I can easily feel with the users, they're excused for disliking, having their desktop cluttered with perhaps 41 greyed out windows ...it's not entirely usefull for the making sense of information, or even worse with Windows users that allthough files are toggled hidden (can't remember what it's today) as a wall of bricks in the bottom of the Filemaker application window.

In my humble opinion will Go To Layout ... with all layouts stored in the same file, never make you wonder if you rembered to make a certain window dissapear! If multiple files tempts (what David are on about, that I agree the deisre hardly makes sense) are used then make all the dealings with layout attached to the "pulled in" table occurences shown inside one file, and certainly not the fm6 and previous versions method to open files in order make a layout occure.

If this is not done completely in the conversion from previous versions is it very likely to pull up large quantities of useless windows.

--sd

Edited July 6, 2006 by Guest

[Steven H. Blackwell]

You can remove the buttons by setting the file to kiosk mode. You must then provide user interface elements for everthing especially including exit application.

You can disable the window widgets by use of SecureFM plug-in from New Millennium:

http://www.newmillennium.com

Steven

[Vaughan]

Nobody has picked up this form the original post...

"My users keep clicking the close button (x) which causes relationships to be lost, with all nasties that result from this."

Relationships aren't lost when files close... FileMaker will open the file again in the background (hidden) when they are needed for a relationship.

Something else is going on here that is causing problems.

[Søren Dyhr]

FileMaker will open the file again in the background (hidden) when they are needed for a relationship.

Good point, so it must be that the password is somewhat different in the opener file, than the enherited from the cascaded opening?? Or the user is prompted and rejects the suggestion??

--sd

[Triodes]

Hi,

Lost track of this topic and have been away for a while...

@Soren:

When users close a window, the window underneath does not necessarily show the same customer/invoice/etc as what they were working on (depends on the last action that was made in that file). This causes problems when the users don't look at what they are now editing (after closing the last window) and justa ssume it was the customer or invoicenumber they had before. Right now I have added exit-scripts to return them to the main menu so they will need to go through all the screens to get back to what they were working on.

@All:

I agree a single file will prevent this, either in a single file with all DB's or a single file out of 43 that holds all the layouts and navigation. My problem is that right now I have over 370 layouts, 400 relations and 1500 scripts spread out over the 43 files in question. It will be less work to start from scratch, but my customer does not want to pay for that of course

The work-around of exit-scripts seems to work for now. All new tables are added into existing files, but the old table structure will remain. I can include the smaller tables into other files, but the larger tables will require too much work to migrate/embed.

[Fenton]

You can override the Close command (in the File menu) with a Custom Menu Set. Reassign that menu item to run your own script. You still need to give them a way to close the file however. So you need another script that overrides the above. One way to do that is to set a flag (global field or global Variable) upon opening. The Close Override script would then clear the flag, then Close the file; run from a "main menu" interface. This is an example of a Close script replacement.

# Called by Custom Menu set, to override the Close command

If [ PatternCount ( WindowNames ( Get(FileName) ); ¶ ) > 0 ]

    Close Window [ Current Window ]

Else

    If [ IsEmpty ( $$noClose) ]

        Close File [ Current File ]

    Else

        Beep

    End If

End If