flashy thingy

[B-Man]

I have created a simple address entry program. I have hid the status area and I am using calclation fields setup as merge fields to give me the CurrentRecordCount, CurrentFoundCount, and CurrentRecord. I have created navigation buttons for next, previous, first and last record. The problem is when I scroll very fast using the buttons I get this flashy thingy (actual technical term) thing goin on where my merge text is at. I know I have read something about how to fix this before but cannot find it. Can someone give me a hand or point me in the right direction.

Thanks

Brian

[Brendon Skinner]

I hear you but have no answer, I am struggling with the same thing now. I will keep you informed.

[Vaughan]

I have never heard of a solution to the flash problem, other than careful and appropriate use of the Freeze Window script step.

[Brendon Skinner]

Hi Vaughan,

I am sorry but I am going to ask a number of questions all at once and would love your input.

Does the flash problem occur across all filemaker applications? I ask because I was kind of hoping that the Filemaker Developer might solve the problem if you create runtime solutions.

Do you generally put up with the flash when building custom databases or do you use the freeze window script step to make the database look more professional?

Does the freeze window step solve the flash when switching between layouts or does it only work when executing scripts that do not skip layouts?

Thanks for your indulgence.

[Vaughan]

I have never used Developer nor bound applications, but I'd suspect there'd be no difference because the "engine" would be identical.

The "flash" when scrolling quickly is in my experience unavoidable. I got over it already. I get a "professional" look through careful and consistent interface design, which includes a *lot* more than how it looks.

The Freeze Window script can prevent a lot of "flashing" while scripts are running (though the screen stays still the scroll bar still waggles about a bit if the length of the layouts changes greatly). Its use is simple...

Freeze Window

do stuff

Refresh Window *or* Go to Layout [refresh]

The final Refresh Window is not always necessary: when the script ends Filemaker has to refresh the screen anyway.

The main use for Freeze Window is to significantly speed up script processing. It's like the Allow User Abort [off] step in that everybody should be using them appropriately but few know how to. With Freeze Window, stick them in they cannot hurt.

Just to re-iterate on the Freeze Window step: it will stop screen updates when changing between modes and layouts, but there will be a "bump" at the end of the script when FileMaker refreshes the screen. But at least there is only one.

[Kurt Knippel]

The problem that you describe it basically unavoidable, because what is happening is that Filemaker is attempting to repaint the data fields on the screen, but you are flipping records so fast that you only see a flashing.

Honestly, the only solution is to present some other interface that does not require quick changing of records, such as a list view. Also Filemaker generally attempts to repaint the back most elements first, working its way toward the front. Changing how the various elements are positioned front to back can affect how the screen is repainted and may help.

[Brendon Skinner]

Thanks for such speedy replies to my queries. Your responses, although dissapointing, were certainly enlightening. I will have a play with the freeze window function in some script steps. I will also go back to basics and scrutinise each of my layouts very closely. I have noticed that it iss possible to remove some flashing while scrolling by careful attention to how the layout was arranged, including omitting carelessly positioned fields and carefully structuring the depth of each layer and its relationship to its neighbour. My main focus is still however on removing the flash when navigating between layouts (Each layout is almost identical to each other except in one small respect). If unsuccessful I can only hope that this will be rectified in later Filemaker versions.

Thanks everyone.

[Vaughan]

The flash is very much dependent upon the complexity of the layouts and the redraw speed of the computer. It'll never be completely removed.

[Rigsby]

Redraws, flashing etc. can be tricky in FM, but there are some tricks and tips to almost remove them completely. If you are getting flashing whilst scrolling through a list (not using a script), there could be something wrong with your list layout. Make sure that no objects are touching other parts or overlapping, for example, a field in the list touching the footer will cause sloppy-flashy redraws. Another trick is to use a script to go to the list layout and then to go to record one, then to the last record and then back to record one. The reason for this is the way FM uses memory. If you have say 50,000 records called up in a list, FM does not have them all in memory, many are stored to a temp file on your drive, as you scroll FM calls up the next block, which can cause slow redraws. If you have enough memory FM will leave any visited records in the memory. Freezing the window, then using the scroll bar to go through a list will not do any good at all. And freezing a window in a script that scrolls and needs to redraw, will make things worse.

In a script this flashing shouldn’t be there for one simple reason. If you are performing a script that is making changes to lots of records, this is going to be taking some time. This is bad for an inexperienced user, as he might even think FM has crashed without some kind of progress feedback. So, for such scripts get into the habit of creating a layout without any fields (except for global fields to show progress), I then use a counter which divides the number of records to be changed by 100, and then increases as the script progresses, thus I can have a status bar running through from 10 to 100%. I then use different graphics stored in global fields, to represent a status bar that also updates as the script increases. Then with a global text field, you can inform the user of what’s going on with a message generated from the individual script like “Omitting records” etc. This technique slows the script down minimally but offers the user feedback, looks very professional, and stops any problems with flashing as only the graphics field with the status bar changes, so the flash is almost not noticeable. There are some excellent techniques on status bars and looping scripts in the book Scriptology.

Rigsby

[BobWeaver]

If your merge field has a really long name like

<<CountOfAllOfTheRecordsThatAreInMyDatabase>>

...you can't reduce the size of the field any smaller than its name, even though the result that appears on the layout may be as small as "126." Hence it will cover a lot of real estate on the layout and make the flashy thingy more obvious.

If you make the name of the field short like <<N>>, it won't overlap as much other stuff, and it should reduce the flashing somewhat (at the expense of self explanatory field names unfortunately).

[Vaughan]

Another merge field tip: the first merge cgaracter is used to specify the formatting for the whole merge field. So you can format the first < as, say 12 point and the rest as 6 point to scrunch it up a bit.

[CG Software LLC]

Try setting the background colour of the merge field to be the same as the background. I have found this can reduce the flashing.