Freeze Window when switching windows

[kennedy]

I have a tabbed interface... relational DB... so, I often have situation where pressing a button goes to another file. When going to another file, Freeze Window doesn't

prevent the window from being displayed with whatever it had before, and then

adjusting to whatever layout the real destination is. This is ugly in an inconsistent way (since to the user, its all just tabs of one application... but some tabs do the herky-jerky, while others transition smoothly... making it unsettling).

So, how do I settle this down? Do I need to Hide the destination Window, get it to switch to the right layout while hidden, and then unhide it? But won't Go to Layout and Go to Related Record, and so on, unhide the window anyway?

Thanks.

[Vaughan]

Here is how I manage the problem:

Firstly, to work well with PCs I maximise all files. I don't try to hide any. It works on Macs but chaos ensues on PCs.

Secondly, each and every file has a script that sets the file up just the way I want. It includes System Formats, toolbars, status menu, text ruler, zoom, scrolling (practically everything in the Windows section of scriptmaker). The script ends with the window being set to maximise and (importantly) the "Refresh Window [bring to front]" step. This last step is the key.

Thirdly, whenever I need to switch files (like with a tabbed interface) the "setup script" in the desired target file is called as an external script. No need to hide the previous window because the "Refresh Window [bring to front]" step ensures the desired window is brought forward, and the maximised window ensures the others are completely obscured. (People often try to achieve this same effect using the "Open []" script step, but it's not at all reliable.)

I hate the way windows are handled on PCs, and this is the only aesthetically pleasing and robust method I've discovered to manage them well. Its only shortcoming is that techniques that rely on non-maximised windows (like Ray's excellent and impressive floating preview palette) destroy the fragile window order.

[kennedy]

But Vaughan, what you describe would seem to suffer the same problem... I must not have described my issue very well... please let me try again...

You're in File A. You're going to layout X in File B. But the last time you were in File B, you were looking at layout Y. Soooo...

If you call the "setup window" script in File B, it raises the window for File B with layout Y displayed, then you go to layout X.

If you first go to layout X, then call the "setup window" script, the go to layout X first raises the window for File B (with layout Y visible), then you go to layout X, then you make sure the size etcetera is right.

Either way, the user sees that he clicked on the tab for X and the schitzo application brought up Y and then thought better of it and brought up X. Ugly and a bit unsettling for most users.

Is there any way to get a file to switch layouts without being raised?

Thanks.

P.S. On the comment about not hiding in Windows... I wonder if my Shutdown script is going to have problems on Windoze... it first hides every file that is open and then it closes each... it does that to avoid redisplays of files that end up invoking updates that re-open files. Thoughts?

[Vaughan]

Sorry, I wasn't exactly complete in my description of the script's contents.

The script in each file looks like this:

Allow User Abort [off]

Enter Browse Mode []

Freeze Window []

Allow Toolbars [off]

Use System Formats [on]

Go to Layout [whatever]

Scroll Windows [Home]

Set Zoom Level [100%]

Toggle Text Ruler [off]

Toggle Status Menu [hide]

Toggle Window [maximize]

(other stuff like Show All Records, Sort, etc)

Refresh Window [bring to front]

Everything between the Freeze Window and Refresh Window steps aren't seen, so the illusion of a seamless interface is created.

Be aware that if you have a tabbed interface, the tab elements have to be *exactly* the same and in *exactly* the same position otherwise there will be a noticable movement. It's nigh on impossible to make the transition competely invisible, but with this script and some well designed layouts it'll be almost imperceptible (once the file is open of course).

I think your shutdown script is going to be less than invisible. Leave those windows alone, just Close the files.

[kennedy]

I think your shutdown script is going to be less than invisible. Leave those windows alone, just Close the files.

On the Mac, its actually calmer with the hides... most of the windows vanish from behind the window that happens to be in front... and then everything closes. Without the hides, you see much more. But none of that is the issue...

The issue is that after you close Files A and B, closing File C will expose whatever file was behind it... and that expose causes it to redraw... and if some of that redraw includes data from a relationship to A or B, you may end up with A or B re-opening. As a result, I could never get all the files to actually close. There were always a couple left open... and it was always a different couple. I could write a loop that kept closing them until they were all gone... OR I could hide them first and then they all close painlessly.

Now the issue you raise is concerning... on the stupid Windoze system I may still have my old "everything didn't close" problem. Not sure... I mostly work on Macs. On Windoze, does Hide actually Minimize, or does it do nothing? If minimize, then I may be alright... as long as Close doesn't restore first.

Is there a better way to script the close? (Without resorting to a loop.)

[kennedy]

The script in each file looks like this:

Allow User Abort [off]

Enter Browse Mode []

Freeze Window []

Allow Toolbars [off]

Use System Formats [on]

Go to Layout [whatever]

Scroll Windows [Home]

Set Zoom Level [100%]

Toggle Text Ruler [off]

Toggle Status Menu [hide]

Toggle Window [maximize]

(other stuff like Show All Records, Sort, etc)

Refresh Window [bring to front]

Everything between the Freeze Window and Refresh Window steps aren't seen, so the illusion of a seamless interface is created.

Is this *a* script, or is this script duplicated for each layout in the file?

I do very similar, but as a single script that each other layout-specific script calls. Thus, the Go To Layout can't be in the middle, but rather must be near the front or the end.

Based on the position of your Go to Layout [whatever], I am guessing you duplicate that whole thing for each layout... true?

However, in any case, here's the key question:

When you invoke this script from ANOTHER FILE, the mere act of calling the External Script actually causes the file to raise... and even if the window is frozen, it is frozen displaying whatever layout happened to be displayed the last time you were in that file... thus, even with your script above, if you start in File A layout Z and click the tab for File B layout X, you may first display File B layout Y while that script is running with window frozen... and when it refreshes, layout X appears.

At least that's what I seem to be seeing... but maybe I am mis-interpreting something that's going on. Or maybe I am seeing OS X specific behavior?

The only solution I've come up with so far is to add a "Blank" layout to every file... then have every tab button first Go to Layout blank, then call the External Script (which will raise the file, but that file will have its Blank layout visible, and then the script will freeze things until it refreshes the destination layout. Thoughts?

FWIW, blank won't be totally blank... it'll have the navigation stuff... the tab bars... so if a user somehow gets that file on top, he won't be totally locked up. Also, that will reduce the flashiness, as the tab bar will never vanish, just the window contents. Thoughts?

[falkaholic]

There is also the possibility that the user could have two (or more) monitors, if the user has moved the windows around, you could end up with a mess.

I have yet to see a end user with dual monitors (and that needs a database to be that idiot-proofed) though. Something to keep an eye out for, since dual monitor are getting popular.

[Vaughan]

OK, attached is a small demo of a simple tabbed interface. Two files, each with two layouts, total four layouts. FMP 6, but should work in FMP 5.x too.

tabs.zip

[kennedy]

Vaughan,

Your attachment doesn't demonstrate the problem I am raising.

I have modified it to illustrate my problem.

Open the file 1.

Click on tab 1a... then 1b... then 2a... then 2b.

All looks fine, right?

Now watch carefully and click on 1a again. Whoops!

Did you see it go to 1b first? What was that!

Now click on 2a. Did you see it go to 2b first?

Now click on 1b. Did you see it go to 1a first?

Now click on 2b. Did you see it go to 2a first?

Those behaviors are far more disconcerting when the layouts are showing real info, much different than this demo file.

Now to see the "go to blank" solution I suggested earlier in this thread,

set the field in the upper left to "Y". Now you can click among the tabs

and never see it go to an oddball layout. In fact, you are always seeing

it go to the blank layout first, but that's real hard to see... since its blank.

My original question was... is there some way to write the scripts so that

you can get to 1a directly from either 2a or 2b, without raising 1 first with

whatever layout happened to be selected last?

OR, is the only solution to add extra blank layouts and make sure all goto

scripts leave the file in the blank layout?

tabs.zip

[Vaughan]

You either have exceptionally good eyes or a really slow computer: I cannot see anything except a bit of a flicker... seriously.

If making blank layouts works for you then do it.

BTW I'm on Mac. I just tested it with Virtual PC 3 (which is really slow on a G3 iMac) and I still cannot see the effect you refer to. I can see a whole heap iof slow-motion window movements, but no tab switching stuff.

Are you using FMP 6 or an older version?

[kennedy]

I am using FMP 5.5 on a Dual 400 G4 Power Mac... not exactly slow. But maybe FMP 6 changed how it raises windows in response to script calls? or somethin'?

Did you flip through the tabs in the sequence that I specified?

And the field in the upper left was set to "N" when you started, right? Hmmmph!

Anyone else willing to try this... is it just me?

The blank layouts solve the problem, but introduce others. I was hoping there was a better solution.

[slstrother]

Kennedy, I went through the tabs in the sequence you described. I can't see what you were describing. Just a flicker as Vaughan described. I am running FM 5.5v2 Dev on Win 2000 Pro, P4-2Ghz.

Perhaps it has to do with how fast your screen redraws?

[Vaughan]

Kennedy -- are you using MacOS X? I'm using 8.6, nothing special or different.

[kennedy]

Yes, OS X.1. I'll be upgrading to 10.2 shortly... its supposed to redraw much faster... it'll be interesting to see if it becomes an imperceptible flicker. Based on that, I'll delay the addition of blank layouts until I see it on X.2.

Thanks!

[Vaughan]

Aha! I thought it might have been something like that...

Well that's what you get for running beta OS software! (My opinion of OS X is not very high.)

Upgrade to FMP 6, it might be a better investment than OS X 10.2.

[Jack]

Kennedy:

Sorry for the late reply. Just downloaded your file and wanted you to know that you are NOT crazy.

I am running Windows and there is a major flicker when going from tab to tab.

-jack

[Vaughan]

Did you test Kennedy's file, or the demo I posted above? Kennedy's version has a number of enhancements that may in fact make flicker worse.

Test my demo (from the message that starts "OK, attached is a small demo of a simple tabbed interface.") and report what you've found. Be sure to include your OS, FMP version and patch level, and whether FMP had any other databases open at the same time. I've found that having other FMP files open with their windows minimised or restored (ie, not maximised) produces an enormous amount of flicker on PCs.

[BFH]

FWIW: I have been developing a multiple-tabbed interface for data entry in FMP 5.5.2 under Jaguar.4.

Seems ok to my feeble eyes, even in Win2K running under Virtual PC 5.0.4 under Jaguar.4 . . .