Closing external window

[macavity]

Another request for help, please.

This problem could occur on a mixed-platform network where users habitually close their FileMaker window when it's not being used.

If a user closes the window of the file they were working in, they may find themselves looking at the window of the shared address database, which would not be good.

Is there a way to hide the latter automatically when the window of a particular file is shut, apart from forcing the FileMaker application itself to shut down when the window is closed?

Apologies if the answer is obvious. The problem presented itself to me purely theoretically, as I don't have the opportunity to check it out in the multi-user network in advance and want it to work straight out of the box. Possibly the "close window" script step works differently from the server than it does when I try it on my own computer, where the remote script step closes the "address" window instantly for all other applications, even if they are currently accessing it.

[mr_vodka]

You can attach a script when a window closes through Custom menus. If you override the default close window script step with yours that has a script, then you can have your script close that other window too.

[macavity]

Yes, I understand that. I can close the other window through a script. What I am wondering is whether the window will be closed for all other users as well. That appears to be the case when I access it through two different applications on my computer. Or will it behave differently when running from a server?

[mr_vodka]

If you have the files on a server, the files will be opened by server. There are no windows. If you are talking about Peer to peer, then all the files that the other users need to connect with have to be open.

[macavity]

Thank you. I think that answers my question. Or does it?

The files are on a server - not peer to peer. I'm trying to avoid a surprise when it is put there on Tuesday.

Up to now each department had its own application and its own table of names and addresses. Now those have been put into their own database and people will occasionally be accessing the address database directly - using a layout on that file (for example to assign firms to certain categories).

What happens if they close the window of their own application? Will the other file still be visible to them? And if so, how can I avoid that?

[mr_vodka]

Sorry you are starting to lose me.

Do these people have a local file that references a served file ( Separation model )?

[Søren Dyhr]

Up to now each department had its own application and its own table of names and addresses.

But hopefully are you about to recognize the flaw you have made in the normalization of the solution.

The question is if we should sustain the continuation of this with quick fixes and remedies - and in particular why?

--sd

[macavity]

No, not as complicated as that. I think I am confusing myself since I'm doing all the work locally - and therefore see both files on my screen at the same time. I've no experience with two separate, related files (except of course in FM versions <7).

Here's an example of what I mean:

When the user in one department, using his specific application, wants to enter a new customer, the address file is opened and he is instructed to search whether his new customer isn't already in there (already a customer of another department). He then either "annexes" the same customer or creates a new one. And is taken back to his own application.

Working locally, the two files simply exchange places, the one in use being in front of the other. If I close the one in front, I see the one behind.

Am I right in assuming that, when they are running from the server, the user will only have one file on his screen at a time?

[Søren Dyhr]

He then either "annexes" the same customer or creates a new one. And is taken back to his own application.

Why not run this in excel instead since integrity means next to nothing here? ... moving data between databases is utterly wrong!

The normalisation question is then which instance of the data is more or less correct any attempt to synchronise are bound to fail eventually!

--sd

[macavity]

I am dealing with an old, inherited situation. There are 5 or 6 separate departments doing very different things. It's almost like 5 or 6 different companies. Creating one single application for all of them, at this late date, would take an unacceptably long time and be unacceptably expensive. Nor am I convinced it would be the best solution anyway.

I am in the process of connecting them to the shared address database in a way that causes minimal disturbance to their work as they are accustomed to perform it. And I'm thankful I've managed to pull it off.

[macavity]

I'm not sure if I understand you, but the address data are stored only in the address database. They are not stored twice, if that is what you mean. "Annexing" simply means setting a relationship.

[Søren Dyhr]

Whew! Then would I suggest you merge all files into one single file with this tool.

http://www.newmillennium.com/index.php?submenu=Developer_Software_FMrobot&src=directory&view=products&srctype=display&id=72&category=FMrobot

The rest is then up to the assigned privilege sets.

--sd

[mr_vodka]

Am I right in assuming that, when they are running from the server, the user will only have one file on his screen at a time?

No. You can have multiple files open on the screen at one time. Perhaps I am having a mental lapse here but I am still failing to follow your setup. So far all I know is that you have multiple files that belong to different departments ( not sure if they are all served on the save server or if they are local copies ). Then there is shared file on the server which everyone accesses. That's about it I 'm afraid.

[macavity]

Nothing is local, everything is on the same server. Each department consists of several people, so all files are accessed by a number of users. Only the address file is accessed by users in all departments.

To ensure that the files are kept in sync, creating and deleting addresses and contacts are scripted and the relevant menu commands are disabled. To avoid confusion it is important for the address file to disappear when someone closes the window of his own, department file.

So my question is still: if User 1 closes the window of his file and automatically launches a script that closes the window (or the file?) of the address file - will User 2 see it disappear as well?

The more I think about it, the more unlikely it seems - but I am not sure how the close window ("by name, not in current file") script step works with networked files.

[mr_vodka]

So my question is still: if User 1 closes the window of his file and automatically launches a script that closes the window (or the file?) of the address file - will User 2 see it disappear as well?

No. lol. Each client has their own session and windows.

[macavity]

Thank you for an unequivocal answer (and the one I hoped for).

[Fenton]

A couple things you might look into. The Hide Window step, which does not cause the application to quit when you do it to the last open window (a PC "problem", from a Mac point of view).

Another more complex idea, for the "people" table(s), would be to consider David Graham's method of multiple "shadow" tables, one for each department, with a central table for most of the data.

That way each department could have their own "people" table, but almost all the data which shows in it is really in the central table. It is kind of like a formal structural method to do what you'd do with Finds (minimal functionality), more like self-relationships (better, yet still problematic). But with much higher functionality, such as a limited set of their people only naturally in List views. So, yeah, it would be a redesign. But there would be no need for this:

"To ensure that the files are kept in sync, creating and deleting addresses and contacts are scripted"

[macavity]

Thank you! I've just changed it to hide window.

I'll look at other suggestions, though the solution I came up with actually works pretty well - and most importantly ensures that the various actions performed with the data continue to function as before. Each department still has its own people table, though it is populated mainly from the central file. Except when entering a new "person", a department sees only its own people data. Each department also can see which other departments have hooked up to the same person.