Hi @daniel.riggs1 ,
When working in Builder rather than Coder, we sacrifice some control for ease of use. Part of that control is that Builder has authority over the screen drawing cycle. Fundamentally, Builder is structured entirely around the screen refresh cycle: it expects to update stimuli, check for responses, execute code components, and so on, on every screen refresh. It also does all its timing checks on that cycle. i.e. even if you are specifying that your stimuli should last a certain period of time rather than a certain number of frames, Builder is checking that time once per frame.
So in our code components, there are certain things we should never do, in order to allow Builder to keep ticking along on the screen refresh cycle (including, but not limited to):
(1) Don’t create ‘pause’ periods in which the screen won’t be updated. For example, we can use
event.getKeys() because it just makes an instantaneous check of the keyboard. But we should never use
even'waitKeys(), as that pauses everything waiting for a keypress, and will break Builder’s screen refresh cycle. We also need to avoid any loops that could last more than one screen refresh (e.g. embedding an
event.getKeys() check within an infinite
(2) We should never call
win.flip(). This will prevent anything happening until the next screen refresh, including any housekeeping that Builder needs to do during that period. So for example, if the code component was at the top, any stimuli below it would not be updated by Builder on that frame. And I’m not sure sure if Builder would even know it has missed a screen refresh, so its timing could then be thrown out. There would be all sorts of unpredictable effects.
So let Builder carry out the one and only
win.flip() on each cycle, so it keeps control of the cycle and we get to go along for the ride.
If you find you need more control than fitting into this arrangement provides, then it really is time to switch to Coder, where you have complete flexibility over what happens and when.
Your question is a good one, and Builder should probably provide some automated warnings if it detects
win flip() or
event.waitKeys() in a code component (checking for potentially long-lasting loops would be harder).