You should ask yourself what calculations/scripts have to refire when you change a checkbox value then follow the logic/chain of events to find the bottleneck.
By your description I would guess the entire report has to be recalculated when the found set is disturbed and the found set is disturbed by the include/exclude pdf checkbox click action.
Without more details we may not be able to help further.
At this point, I've set things up so that there's no need (so I think!) to recalculate anything upon changes. The idea would be:
1.Run report first time to screen (perform script, let summaries calculate, take a little time)
2.Click and Y's and change them to N's
2a. Scroll down (probably to records not onscreen) - click any other Y's to N's as required.
3.Click a second script trigger to rerun the report one more time only to omit the N's
However, the issue is arising at step 2a in that, before changes were made to the Y/N text field, scrolling down was quick. After any change is made, it processes slower than the initial script find/render of step 1.
Hope that has clarified things somewhat.
So by way of an update, I've now removed the script I use to change a Y to N and vice versa, instead trialling this with a keyboard entry into the same field.
I now don't have any issues moving through to the next 32 records as I did before...
So it seems that something in the scripting area is causing a hang, although I've performed a Halt Script.
Filemaker at its most evil...I had some ExecuteSQL fields positioned off screen, but on the layout. Removing there in the past gave amazing gains in speed, but I kept them just in case. Just now deleted them from the off screen part of the layout and everything is working fine.
Moral of the story, never use ExecuteSQL...ever.
ExecuteSQL is an indispensable tool for FM development.
Just like any other "tool in the box" you need to know how and where to use it.
in carpentry using a palm/hand plane when you need a thickness planer just because you don't know how to use the thickness planer machine will cost you lots of extra time and frustration.
I hear you Kris.
The main time I've needed it is for working and getting calculations based on data outside the found set. However, on several occasions I've been subjected to massive speed overheads due to the nature of calculations I'm doing that it's been a relief to remove it.
In this case I was able to replace it with scripts and a data warehouse of static values, saving so much time on report loads.
I will however merit it when used in combination with virtual lists. That massively sped things up for me in another area of the solution I am developing.
off-topic, but Kris, that really makes want to get back into the shop. It's been years.