Window flashing

[sandyinlet]

My script has two steps. 1) creates a new window, positions it and goes to the required layout. And 2) before finishing it must also jump to a different layout, fetch a current value, and then return. To avoid window flashing I'm putting step 2 above off screen. However, no matter what I do, including adding Freeze Window steps all along the way, there's still a quick flash.

Am I attempting the impossible? Or is there a better way?

Set Variable [$WinTop; Value: Get (WindowTop)]

Freeze Window

Move/Resize Window [Current Window; Top: $WinTop + 200]

Freeze Window

Go to Layout ["Companies|Details" (COMPANIES)]

Set Field [GLOBALS::Utility1; COMPANIES::CompanyName]

Freeze Window

Go to Layout [original layout]

Freeze Window

Move/Resize Window [Current Window; Top $WinTop]

(Disabling all but the first Freeze Window just extends the flash a micro-second longer.)

Feedback appreciated.

[Vaughan]

What happens if you don't try to move the window, just freeze it?

[sandyinlet]

What happens if you don't try to move the window, just freeze it?

The flashing stops. Obviously I was over doing it. Thanks.

[LaRetta]

Another way to eliminate flash during a script run, is to use Developer layouts without any fields. Unless you specifically need Insert...[] or Paste[], it shouldn't be a problem. Working mostly in Windows, we get more flash than Macs (fact). I would rather use a few null layouts than risk ANY flash from overlapping objects, portals or aggregates. Null layouts rock. Of course if Freeze Window solves it, that's the best to use but sometimes null layout works wonders as well.

Now, if FileMaker allows us to organize layouts, I'd be a happier camper! :king:

[Vaughan]

Agreed LaRetta, about the "developer" layouts. Except I call them "Base" layouts; "Developer" layouts are those that I use for development that might have portals or fields displayed that allow for debugging. But that's a naming convention, not a matter of right or wrong.

They are now a part of my regular development standard. They *never* get deleted so I don't have to worry about GTRR steps breaking at some time in the future because they all point to the developer layout, and are then redirected to another interface or print layout as needed. If the GTRR went directly to the print layout, and then that layout gets deleted (or even pointed to a different table occurrence, as sometimes happens with report layouts as they evolve) then the script will break.

Other tips: Make sure the developer layouts are all set to Form view because it's faster than List or Table views (data has to be pulled down from the server for all visible records with list or table views) and make sure the layout is smaller than any window it could be displayed in, otherwise the scroll bars will briefly activate even if the window is frozen.

[LaRetta]

make sure the layout is smaller than any window it could be displayed in, otherwise the scroll bars will briefly activate even if the window is frozen.

I didn't notice that, thanks!

[K1200]

LaRetta, could you elaborate some on the use of Null Layouts.

I just spotted this thread and wasn't able to find any other references to their use. Do you mean simply having a Blank layout and then using GoToLayout[blank] in places where FreezeWindow isn't helping? And is there an original source I can look at for more information?

BTW, I've applied every techique that you and others have mentioned over the past two years, and had resolved to just accept the remaining flashing -- which has kept me from even searching for further solutions. I'm certainly glad to hear of anything else that will help.

Thanks.

[LaRetta]

Yes. That is exactly what it means. It sounds like we are in same boat. Take tab panels ... if you have a portal on a tab panel, it can flash. If your user is scrolling through main records, it can flash a LOT. All you can do is 1) make sure field is a bit overlarge (if field is small (particularly in height), FM seems to force the text into it with an aggressive flash), 2) make your portal close to the background color - light is the answer always and 3).. . Oh, no, I won't go into ways that help ... there are other posts about it.

But most of us have found out (the hard way) that having a summary on a layout sucks (if the layout is only to jump elsewhere or isn't used for specific display). A few years back, I ran some speed tests on looping and layout switching. One test used null layouts, the other used layouts with simple portal and two main table fields (not aggregate or calculation). I varied the tests until I became thoroughly confused. But what WAS clear is that the null layouts 1) flashed less in all situations and 2) rendered more quickly under 35% of the situations.

If you know your record-set is small; if you know your layout isn't heavily burdened; and if you know you don't have aggregate or summaries, then using a regular layout may be fine. But when you get up into the large numbers of records; layouts with 30-40 fields on it; 20+ row portals, multiple tabs and so on ... flash increases and speed decreases.

I plan to run new tests with vs. 10 ... it seems to be slower on redraw. If so, and I may be wrong (it's only observation and NOT tests), null layouts might be especially more valuable until vs. 10 has been optimized by the engineers. Freeze window stops much of the rendering but it doesn't stop it all, particularly when you have a complex (long) script which has several layout switches, refresh windows and so forth. Null layouts also have an added benefit ... they do not require opening a related table (if a related field is displayed on a layout you've just switched to). And they do not require recalculation of an unstored calc if it happens to be on the layout, either.

Back in vs. 7, I tested file size increase when creating a null layout. It didn't increase at all until I had created (IRCC) something like 6 null layouts. Of course they make scrolling through them more of a hassle but they, similar to value lists, take little resources, I think.

UPDATE:

And is there an original source I can look at for more information?

I don't recall much discussion about using null layouts, sorry.

Edited March 11, 2009 by Guest

[K1200]

Thanks for the recap of some of the methods. I wasn't aware of #1, but it correlates to what I've experienced on a couple of my portals:

1) make sure field is a bit overlarge (if field is small (particularly in height), FM seems to force the text into it with an aggressive flash)

I'll be back at my development system in a couple of days and look forward to giving this and Null layouts a try. I'll report my results to help fill in the base of knowledge on this subject. If I can quell the agressive portal flash, I'll be elated!

[Darren Burgess]

I happened upon an interesting solution for object flashing in windows. I am not sure if this applies to your situation, but it worked great for me. In my solution, there was alot of flashing when the user navigated between layouts and from record to record in the same layout. What I found was that if the window height changed on navigation, then the flashing was eliminated. The solution was to toggle the window height by one pixel in the navigation script. The solution stores the window height in a variable on file open. This solution worked along with making sure that stacked layout objects were properly ordered. If there is a background shape object on a layout with fields on top of that, send the shape object to the back, then send the fields to the back, then bring the fields forward until they reappear.

Darren Burgess

[LaRetta]

Hi Darren,

There are many posts (check out The Flash Effect for links to others as well). I thought I knew all the tricks but I will certain add window height adjustment to my tool kit! Thank you for mentioning it!!

LaRetta

[Darren Burgess]

Yes, discovered the window height trick quite by accident. When I was troubleshooting the issue, I found that navigation between certain layouts would cause flashing, whereas others it would not. Eg Layout A to C would flash but A to B would not. Then noticed that the body parts of the A and C were identically sized, where A and B were slightly different. This lead to me creating a script to tweak the window height by one pixel. I have no idea why this works, and it is dramatically effective. Note that my navigation script have a fair amount of stuff going on behind the scenes - not just simple go to layout. I believe that the flashing was exacerbated by the script.

Darren

[Steverino]

In our case, the flickering redraw occurs after the window has been minimized and then re-displayed.