Is all of the window management issue driven by this: "I have a home screen which I will keep open all the time (so the user doesn't close the DB by accident)". If so there are easier ways around that problem.
What other features do you want the multiple windows to provide that aren't able to be provided another way? I find the management problems that multiple windows bring are very rarely worth it.
Basically, I'm trying to mimic the windows functionality of most windows based systems. I'm quite frustrated with the special work arounds I have to do in order for my DB to even look like a normal windows application....
It's not a requirement to have the home screen open all the time. I'm thinking I may even want to just hide it, then have a link to it in a custom menu.
To be honest, I'm not sure what is the best way to implement a windows like system. I have gone back and forth for almost 9 months now....
What I have learned is that it is not very easy to prevent the user from resizing windows, and so I think it's best if I just accept the possibility of windows being minimized, etc. BUT, I have to manage it (i.e. make sure the user doesn't have a mess 20 windows open).
I'm also trying to avoid the situation where a person closes the DB because they closed the home screen (or the last screen open).
Sorry for the long explanation. Hope this helps.
Sorry to ask the same question again, but I didn't pick up your answer to it: "Is all of the window management issue driven by this: "I have a home screen which I will keep open all the time (so the user doesn't close the DB by accident)"?
When you say you've spent 9 months trying to mimic the windows functionality of most windows based systems, what functions are you trying to mimic?
"it is not very easy to prevent the user from resizing windows". So what? What problem does that cause your database if the user wants to minimise it and get on with something else?
"I have to  make sure the user doesn't have a mess of 20 windows open" - why would that happen? I have never seen a user do that, unless it is the database itself (ie: scripts in it) that are opening the windows.
I have a feeling you may be trying to solve a problem of managing a potential cascade of open windows by providing scripts that trigger the new windows. If you removed the need for the script to trigger a new window you will remove the window management problem.
I try to limit my Database interfaces to no more than two windows open at any given time. A main window used to display data on FileMaker layouts and a secondary window that opens when needed to serve as a customized "dialog box" for cases where such data entry is needed. This allows me to keep the windows Maximized (this is on a windows system), so that the user never has to deal with windows inside of of the application window nor do they have to deal with multiple windows open at the same time.
Instead, navigation buttons change layouts from within the same layout to take users to the various reports and data entry screens that make up a given solution. This avoids the whole window management problem which can indeed become very confusing to the user.
I agree w/ Phil's approach, but with the wide screen monitors of today, I wanted to take advantage of looking at multiple windows at the same time. I also wanted the user to feel like they are in an app that is similar to what we use today (quickbooks).
Sorsbuster, to answer your question: no. That's not the only reason. I've been going back and forth with different methods of handling the windows. I like that you can have an invoice open, a sales order open, and a quote open at the same time.
It seems there is either the web type of design (i.e. one window at a time with links to every possible useful page), or the windows type of design. I've trying to get a windows type of design, but I keep falling short and ending up with too many scripts.
Right now, I have a script that, when the user closes the window, it checks to see if it is the last window open. If it is, the program prompts the user if they want to close the DB. This helps to prevent the user from accidentally closing the database when all they wanted to do was go back to the home screen, or exit what they were doing.
I would like to have a custom menu, so that the basic layouts are available (i.e. customer list, quote list, etc.), and save the home screen for our process (i.e. create new sales order, create invoice, ship order, etc.). I'm concerned that the user can open the same window twice with this set up.
You can use the windownames function to get a return separated list of all windows that are currently open. You can then use the filter values function to check the list for a specific window name.
That's what I was originally asking for. Since my window names are more or less variable, shouldn't I check to see if that *layout* is open, and if so, close it?
I don't know if I can do that however.
There is no function that can do that.
You'd have to build a table where each time a window is created you log the window namd and selected layout. Any layout changes after the window is opened would also need to update the record for that window in this table.
Once you've done that, you can check the table to see what windows already have that layout open.
Sorry to bang on about it, but I can't get my head round the need to climb the Window Management Mountain. (My Lazy Gene says rather than solve the problem, why not just remove the problem?) Opening multiple windows in FM has been available for a long time, and the number of times I've seen users open and tile two windows is very seldom. It facilitates the odd forensic investigation of something very rum, but usually if several listings need to be constantly compared on the same screen then portals side-by-side usually do the trick. If just a quick and easy flick from one layout to another is needed then tabs (or simulated tabs, or just straight buttons) do the trick, and if it is that very occasional forensic research query then manually selecting 'New window' and 'Tile Windows' does the trick.
If the user needs to see listing sof Order Lines, Delivery Lines, Invoice Lines, or whatever, all at the same time, with some common connections, then why not just show them all as portal listings on the same screen? Have tabs to allow flicking between various combinations of portals?
I see your point, and I need to give it more thought. I personally LIKE the windows scenario. Without it, it's more like designing a website.
My main concern was that I had to have a layout open so that the user doesn't close the DB file down when they close all windows. This created a two window minimum session, which made me concerned about the user using the min / max buttons.
I hate to say this, but with Access, all of the "window management" is handled for you. One major difference is that you don't have to actually navigate to a layout / form in order to find data, you can query the DB "behind the scenes" with queries.
Your opinion has validity, and I think I will go forward with a 1 window design with the exception of psuedo pop ups.
Thanks for your time and support.
Ok, so I'm moving to a 1 or 2 layout format. Scrapping any type of "windows" functionality.
However, the first problem I run into is that the user can close the current layout by clicking the little "x" in the upper right of the layout. Since the current layout is the only one open, it closes the database. Bad news.
I thought I had a script to handle that which basically said:
if Get(LayoutName) = "Home" then
exit script (true)
exit script (false)
goto layout "Home"
The "exit script (false)" command doesn't seem to take effect and the database closes.
Basically, I need the following functionality:
If the user is not at the home screen, and they click close, it takes them to the home screen.
If they are at the home screen, then ask the user if they want to exit the system. If so, exit. if not, don't close the layout/file.
THEN, if the user is looking at a psuedo pop up (what I call a modal dialog type of layout), then they also cannot close the window, but instead have to select an item or "cancel".
How do I do that?
It is much easier than that to stop accidental closing of the file. Simply have a script that is one line: 'Halt Script' and make it the script that runs on file closure. However I would strongly recommend that you don't do that, as there are many valid reasons for a user to want to close a file (including for you, the developer).
In those circumstances I normally have a closing script which checks for the Privilege Set of the user, and if it is Admin, say, then it closes. If it is not it offers a dialogue reminding them that it is not normal practice to close the file, and are they sure?
You can add as many warnings, "Are you sure?", "Are you really sure?" as you think are desireable.
To emulate your modal dialogue I would use FM's Custom Dialogue script step, or take the user to another dedicated layout that looks as much like your modal dialogue as you want it to.
When someone of Phil's experience says "I try to limit my Database interfaces to no more than two windows" and qualifies the circumstances where he would find a use for a second window as one which "opens when needed to serve as a customized "dialog box" for cases where such data entry is needed" I think we can be assured that the ease of using layouts and custom dialogue boxes is the way to go.
If you do want to play around with Pseudo dialogs (they can be handy when you want formatted input not available in custom dialogs), you might check out this file which uses several such: http://www.4shared.com/file/8orL8apk/FMP_Bugs.html