[FM7] Windows, windows, and more windows

[Andy Robo]

G'day

So I've got this awesome looking database, and due to my inept scripting, I'm throwing up windows and giving them fancy names left, right and centre.

As you can imagine what often happens is that I have users moving between windows using scripted buttons, but sometimes these buttons, in an effort to be generic, and cut down on dev time, don't deal with the windows in an intuitive way. ie. the windows stay open when they probably shouldn't, and close when they could have been left open.

The real stinker comes when a user manages to navigate (or just click) on a window and repeats a script by clicking on a button already clicked - an annoying result is that I get two windows showing the same layout open - confusing for people who just want to get the job done I guess.

My query is does anyone have a nice simple step for ensuring that when a user initiates a script step which calls a new window that it can check that the intended window isn't already open - and if it is just select that window.

I am aware that there is a GET (windowVisible) function - but I don't know how to script it so that it checks for a specified window.

Thanks

Andy

FileMaker Version: Dev 7

Platform: Mac OS X Panther

[Vaughan]

My initial testing indicates that there is nothing "nice and simple" to manage windows. It takes care and thought by the developer. And planning, lots of planning.

First thing I do is standardise on window titles. Make them unique for each purpose, like "Data Entry" and "Contact List". Plan to have each open window named differently.

Before creating a new window I first check to see if the window is already open (here is where the standardised names are important). If the "Contact List" window already exists then select it (and perhaps resize it, change its position etc.) otherwise make a new window called "Contact List" and set it's layout, position, size etc.

I've found that Windows OS won't allow a mixture of maximised and restored (un-maximised) windows at the same time: as soon as one window is restored all of the other windows un-maximise themselves and become restored, so it's all or nothing. In FMP 6 and earlier I kept all windows maximised; in FMP 7 I reverse this and keep all windows restored.

It's only through this careful and structured management of windows that any resemblance of control can be maintained, otherwise it becomes a huge interface mess.

I'm still learning FMP 7 but this has been one of my earliest discoveries. My recommendations may change in the future but this is my best practice so far.

[MoonShadow]

I have also switched from Maximized, Vaughan, and have standardized the size/placement and naming. However, I need some help with it. The plan was to script Windows placement and size as a separate set of scripts which would be called from within my main scripts. I kept Set Window Title with each main script because I usually will use Get (LayoutName) but I will also be using calculations.

So my FullWindow script is:

Move/Resize...

Height: Get ( WindowDesktopHeight ) - 4

Width: Get ( WindowDesktopWidth ) - 4

Distance from Top and Left at 0

Set Zoom Level [Lock; 100%]

Select Window [Current Window]

It works, for what it's worth. But when User is in another window, they will occasionally drag the new smaller window partly off the page and leave it open. When focus on that window is lost, the next FullWindow script executed messes up. The FullWindow layout's scroll bars are under the main FM scroll bars. I lose real estate that I had before and I can't make it 'come to the front' again like before. I've already lost screen space by dropping into window, I don't want to also lose that scroll-bar space.

If I can't fix my FullWindow script, I may need to better control the open windows - possibly returning each open window 'type' to its starting location (so they are within bounds) or maybe force a Close of those errant open windows if outside the designted placement before executing FullWindow. How are others handling this?

FileMaker Version: Dev 7

Platform: Windows XP

[Vaughan]

I'm checking for open windows (by window title) before opening new windows.

The decision whether to adjust/resize a window that has been moved and resized by the user is a tough one... as a user I hate when the program moves my stuff around (I may have patiently arranged the windows to positions that I find optimal for my setup for instance). On the other hand as a developer I want to plan for all contingencies too.

I'm currently choosing NOT to adjust windows that are already open, on the premise that the user has placed them where they want. However I'm thinking of putting in the option that if the user holds down the Shift key the script will adjust the window to the default (initial) position. Perhaps the best of both worlds.

[MoonShadow]

Too bad the Bring All To Front isn't available on Windows. That sounds like the perfect fix for the main window scroll bar problem.

Vaughan said... user holds down the Shift key the script will adjust the window to the default (initial) position. Perhaps the best of both worlds.

How would you tell which windows are open or which are partly off screen? If your [shift] wasn't executed until focus had been switched to another window, you'd need to specify the WindowName, right? Using WindowNames()function? Or do you write the names to a global as your scripts run? How do you script a SnapHome shortcut for all open windows (or even just offscreen windows)?

I tried Minimizing them (by name), running FullWindow then Restoring. It solved my problem (no main scroll bars displayed), but it looked pretty ugly handling only 3 windows (flashed). And they jumped to the front (on Restore) which defeats FullWindow script.

Maybe I

[Andy Robo]

Thanks for the discussion guys...

For the most part I was doing what you're doing vaughan.. checking for windows before opening them... but Iike moon's idea of creating a script for some parts of that operation - I too wish I could narrow this down to a science...

jees ya learn a lot at this place!

Andy