I have a script on a button that will go to the next record, run a test, with one result will go to one layout, with another result will go to another layout. This works fine and all, but there is a bit of a delay between switching layouts. My question is, is there a way to run a calculation that can determine what the next record is without going to the next record? Maybe based on a calculation field?

You can build relation by which you can see what contains next record. But if you delete any record, you must to think that relation dont corrupt.

If you are using FMP 7 (and I'm not, so I cannot test this idea) make a self-join on the RecordID serial number, but use the > operator. This (I hope) will relate the current record to all records with bigger serial numbers.

The first related record will then be the next record.

If you are using FMP 7 (and I'm not, so I cannot test this idea) make a self-join on the RecordID serial number, but use the > operator. This (I hope) will relate the current record to all records with bigger serial numbers.

...Only it doesn't respect found set and sort order. While jumping to disconnected table occurences does it:

http://www.sumware.net/robfm/savingfoundsets.php

--sd

And how is a calculation determining the next record supposed to speed up Filemaker going to it?

If the found set and sortorder should be respected, then can't I think of any ...can you??

--sd

No, not really. Heathbo is not telling what the test is. Perhaps, even likely, the problem is there. Even if the test's result could be known beforehand, it would only shift the problem one stage backwards in time (instead of 'go to next record, do the test, select the layout' you would have 'go to next record, select the layout, compute the next next record, do the test').

Here are the details. There is a field called card type in one layout but not in the other. The script go to the next record, checks to see if the value in the card type field is greater than 0. If it is, the script will switch to the layout with the card type field. If the value is 0 (as in nothing in the field) then the script switches to layout without the card type field.

But if you have script, why you dont want do it by script?

Hi Heath

Since you're on a Mac could you do it this way ...but I havn't got the faintest idea how to make it x-plat.

Examine the upload - but I need to caution you, you have to have the 2 fields shown in the layout ...say in 1 point or such or hidden under a graphical thing??

--sd

ChainGang.zip

I have made a simple test and I see no delay. Perhaps your field is an unstored calculation, perhaps your script has some weirdness - frankly, I am tired of guessing.

This is my guess as well, the determination of which layout to go to must be a summaryfield or a selfjoin on a vast number of records???

--sd

The original problem was, when the script would run it would go to the next record then change layouts. The problem I kept running into was, you would see one layout before it would switch to the next. Inother words the delay was the script running to determine which layout to go to. So my thoughts were, if the computer knew ahead of time which layout to go to before going to the next record you wouldn't see the wrong layout because there wouldn't be a delay.

It sounds as if adding a simple Freeze Window step at the beginning of script could be useful.

> the delay was the script running to determine which layout to go to

I don't think so. More likely, there are some elements on your layout that are computation-heavy, so it takes time to draw the layout before switching to the other one. In any case, Freeze Window should cure this.

Thank you. Freeze Window fixed it.