I was intrigued by that behavior and made a small test model – see attachment.
It turns out that forever buttons will not always stop when ticks are cleared.
In fact, when not restarting the tick counter, the button does not stop at all, and it is even impossible stopping the button by clicking it. (Halt is the only way.)
This might be system dependent. I have tested this in Windows 10 and Windows 11.
(The behavior is reproducible in all NetLogo versions from 5.0, when clear-ticks and “Disable until ticks start” were introduced, up to and including version 7.0.4)
Interestingly, after replacing clear-ticks in all go procedures by resize-world with random valid dimensions (in NetLogo 7.0.4) the forever buttons don’t stop either.
Conclusion: trying to stop a forever button by clearing the tick counter is unreliable.
Thank you for picking it up.
It was not really intended as a bug report. In my opinion stopping a forever button by clearing the tick counter is not intuitive. But that might be my Computer Science view…
Maybe, the documentation of clear-ticks (and resize-world?) can make this explicit?
I agree that it might not be the most intuitive way to do it, but the behavior in 7.0.4 is definitely a bug, because a forever button can pop up and appear to be halted while its code is still secretly running in the background. The documentation for clear-ticks does indicate that this is the intended behavior, saying that it’s “useful if you want to set the model to a ‘pre-setup’ state with some forever buttons disabled”. But maybe this could be worded more clearly, let me know what you think.
OK, I agree that the behavior in 7.0.4 is wrong, even if undocumented.
I have been thinking about some text for the entry on clear-ticks in the NetLogo Dictionary. The more I think about it, the more my idea is that stopping a button by clear-ticks is flawed.
The text would be something like “clear-ticks stops any running forever buttons that are labeled as disabled until ticks start”. On the one hand, this is too complicated. On the other hand, it is not yet precise enough. Does the buttons stop immediately, or before their next “step”, and how to formulate that?
It is clear and intuitive that a forever button stops either by the user clicking it again or by the code of the button itself calling stop.
But stopping because any code resets the tick counter is another matter.
Stopping forever buttons immediately on clear-ticks would create a concurrency nightmare: it is unpredictable in which state the code stops.
But not stopping immediately will keep the original problem that the (still running) code could refer to the tick counter, or not stop at all.
So, stopping a forever button other that by stop should be left to the user.
Any problems by clearing the tick counter in the middle of running code are essentially up to the person writing the model, as with other code that violates some implicit assumptions of the model.