How to create an empty subject pause screen consistently

I searched the forum, and found this had been previously addressed, on the subject screen, unless a command is sent to clear the screen, if a stimuli was toggled on, it will remain on.
A way to clear the screen is to call the idle() function during the trial code.
It makes sense that the escape_screen() function pauses and follows a similar format, where anything currently on the screen, remains on the screen.
I understand the value of having stimuli remain on the screen during the inter trial interval.
However, I believe there is also value in having a dedicated function that can guarantee a clear subject screen upon pressing it, and have it also pause the task.
One use case, being that we train our monkey that looking at a fixation dot starts the trial.
If during the pause, a fixation dot is not cleared, the monkey could be frustrated and confused, that there's a persistent fixation dot on the screen that when stared at, the expected behavior does not occur.
Previously I had not had this issue, as the task was fairly simple, and we always called idle() at the end of a trial, no matter what kind of TrialError, so using escape_screen() seemed to guarantee a clean screen.
However, now, we have a far more complicated task, and there are cases where we want stimuli to remain on the screen during the inter trial interval, and other times when we don't during normal operation.
I tried tackling this with a ludicrous amount of if else statements, but during simulation testing, I had immense difficulty guaranteeing the task would perform as expected, while still ensuring that when the pause button was hit, a clean screen was guaranteed, as there always seemed to be some kind of stimulus that would "leak" through and remain on the subject screen during the pause, and then "fixing" that would cause the task to not run as expected.
I was hoping that using the hotkey, and calling idle(0); in addition to escape_screen(); and assigning that to a key would cause the desired behavior, but that does not appear to be the case, pressing the pause key, and breaking fixation at the right time can usually cause at least a few stimuli to stick around.
Would it be possible to write a function such as "clear_and_pause_screen(); that would both clear the screen, and pause the task?
I spent a bit of time trying to get this to work, but given I couldn't, and since I think this would be a broadly useful feature, would you have any advice, or do you think this could be something that could be rolled out in the next update?
Thanks for your help!

Show your code first, please. I am sure you made some mistake in the script. Clearing all stimuli is just one line code as shown in this post, so I do not understand how that is different from having a dedicated function.

I did find I made a mistake, the "mysterious" stimuli and fixation dots that remained on the screen, that's because I called the idle() function in the wrong parts of the many if else statements used to in my code.

However, I still wish to clear a "correct" trial during the pause menu. Allow me to elaborate.

We show a few stimuli to the subject, one group which corresponds to scenario A, and one group to scenario B.
If the subject breaks fixation during the stimuli presentation, the screen should be cleared, and proceed to ITI.
This has now been fixed, by placing the idle() function in the proper places.
Next step, the subject has to identify whether scenario A, or scenario B has occurred.
This is done by fixating on an upper circle, or a lower circle, for A or B.
If the subject gets it correct, the corresponding circle on the top or bottom should remain on the screen during ITI, while reward is dispensed.
If the subject gets it incorrect, first, the selected stimuli appears, but shortly after, the correct stimuli remains on the screen for the longer ITI, while no reward is dispensed.
As expected, if you get to the end of a trial, and idle() is not explicitly called, as is the case here, the top or bottom circle will remain on the screen during ITI, which is the desired behavior during normal operation.
However, on the rare occasions a pause is necessary. We used escape_screen(), which waits until the current trial is over, then pauses.
As mentioned before, if idle() is not explicitly called, the pause screen will not clear the stimuli.
If the subject had broken fixation while pause was called, then the screen will be clear as desired. However, if the subject gets it correct, then the top or bottom circle will remain on the screen indefinitely, for in the normal task case, it was not cleared.
In short, we do not want to use idle() on some trials, and keep some stimuli on the screen during the ITI. However, when we pause, we want to be able to clear all stimuli on the screen with the press of a button.
Now that I've had a few days to think about this, I realize its likely possible to include a check for the pause by adding more if else statements, and clear/don't clear stimuli to our desire. I was just hoping there was a more straightforward way to just "have the screen be clear" during a pause, preferably with just a single function.

So you want to clear the screen when you explicitly pause the task. Is this simple enough?

% at the beginning of the timing script
paused = false;
hotkey('esc', 'escape_screen; paused = true;');

(put your task code here)

% at the end of the timing script
if paused, idle(0); end

Unfortunately, that method does not work.
I tried both your exact code, as well as a few variants of it that involved TrialRecord.UserVar, calling idle(0) before escape_screen(), but I think once escape_screen() gets called, it somehow interferes with idle(), or perhaps assigning values to variables in the hotkey() function does not work as expected.
I have tried this on the latest version of MonkeyLogic, and I couldn't get your simple method to work.
I copied your code exactly, put the if paused idle(0) on the literal very last line of the behavorial file, and when I use the hotkey, it does pause, but when it does, it still leaves the stimuli on the screen while the pause menu is up.

It does appear to work on paper, but in practice, perhaps there's something unexpected going on in the background?
Could you try it out, and see if you can replicate my problem?
I don't think attaching my particular code would be helpful, but if you don't have a ready made example to test it on, I could make a stripped down version of a task to replicate the issue.

escape_screen() does not terminate the ongoing trial but just tells NIMH ML to pause the task after the current trial. There is no point of calling idle() before or after escape_screen(), if your code still presents something after that.

What is important is not putting idle() at the end of the script but running it for the last command of the task. Your code probably has some exit points in the middle that prevent the script from being executed to the end. Add disp() to the last line as in the following example (colored in red) and see if the message is printed when the task is paused with ESC.

This example removes the box when you pause the task with ESC, but not with x.

paused = false;
hotkey('esc', 'escape_screen; paused = true;');
hotkey('x', 'escape_screen;');

box = BoxGraphic(null_);
box.List = { [1 1 1], [1 1 1], [5 5], [0 0] };
tc = TimeCounter(box);
tc.Duration = 1000;
scene = create_scene(tc);
run_scene(scene);

if paused, idle(0); disp('Screen cleared after ESC'); end

If you show me your code, I can help you pinpoint where the problem is and we both can save some time. When you do so, please provide your entire task code, not a stripped version.

This code does perform as expected.
What is not entirely clear, is what is considered a premature exit point?
I had not included any return statements in my timing script, (I used the scene v2 framework).
I followed your recommended instructions, first, generate all scenes, then, based on how the error_type has been changed, determine which scenes to run.
It is possible that one of my stimuli generating scenes, runs with a bit of a delay, and it is possible it draws the stimuli, after all stimuli is cleared at the "end" of the trial.
I'm sure I could track it down and fix it. Please let me know if you think of another shortcut.

Obviously your code is not working as you think. There is no way that I can help, without knowing what you wrote.

"It is possible that one of my stimuli generating scenes, runs with a bit of a delay, and it is possible it draws the stimuli, after all stimuli is cleared at the "end" of the trial." >> No such thing is possible.

Okay, I have found a way to replicate the bug in a different much simpler task, and I think its now relevant to share.
I was writing the following task:
1. Fixation dot appears on a black background.
2. The moment fixation is acquired, flash screen white for 100 ms
3. Sometimes give a reward.
In simulation mode, if you move the mouse quickly past the fixation window, it'll flash correctly on the experimenter view.
However, on the subject screen, it'll just stay white in between the 750 ms inter trial interval, sometimes, but not always.
(Stimuli not clearing the way they should)
I have made this code work by adding far more idle(0) in various places, but as it is written, logically, it should be cleared if the trials are correct, yet it still doesn't always clear on every correct trial.
Although this doesn't exactly relate to pausing the task I would assume the same mechanism is causing the bug.
The logic of the code seems to be sound, I think there's something I don't understand in the background that's causing something to break.
I have included the exact configuration file I used to run it as well.
Could you have a look at this one, and let me know if you can replicate my bug? I'll send a video recording if you cannot.

I ran the code you attached almost for 300 trials either by putting the mouse cursor in the fixation window or sweeping it across the screen. Not a single time did the subject screen stayed white during ITI.

Your script produces only correct trials, so I do not understand what you mean by "if the trials are correct".

[youtube.com]
I have filmed it on my system, and its exactly the code I zipped up.
Also, it appears if I keep my mouse completely still, it waits almost a couple of seconds to get started, if I leave it in the center. (mouse simulation mode)
Now, in real life, eyetracking is stochastic so I doubt it would have any impact on real experiments, but still strange.

Your system does not seem to work correctly. Whether you keep your mouse still or not, the fixation should be detected in no time, if the cursor is inside the window.

The data file included in the zip says that your system has three monitors. Does it?

Have you run the latency test? What does the result look like?
https://monkeylogic.nimh.nih.gov/docs_MonitorSetup.html#LatencyTest