2

I have code that contains the following repeating pattern:

  1. Ask the user to press    ⏎    to begin computation (using input).
  2. Perform some lengthy computation and display some info to the user.
  3. Wait for the user to press    ⏎    again to proceed to further computations.

The problem I am facing: if the user presses Return/Enter/   ⏎    more than once after the 1st prompt appears (presumably by mistake), these presses are intercepted by the following prompts which causes the rest of the code to execute.

The desired behavior: I would like to discard any number of keyboard events happening after the acceptance of the a prompt and before the appearance of the following one, such that the computation does not proceed without explicit user interaction with each prompt.

Code that reproduces the problem:

function q34593155()
%% // Init  
  clc;
  import java.awt.Robot; import java.awt.event.*; robot = Robot;
%% // 1st prompt:
  disp('--- Some initial info the user should see ---');
  [~] = input('\nPress "Return" to start phase 1.\n','s');
  disp('Please wait while computation is running...');
  %// Here we simulate an additional press:
  robot.keyPress(KeyEvent.VK_ENTER);
  robot.keyRelease(KeyEvent.VK_ENTER);
  pause(2);
  disp('--- results of the 1st part ---');
%% // 2nd prompt:
  [~] = input('\nPress "Return" to start phase 2.\n','s');
  disp('Please wait while computation is running...'); 
  %// ^ Should only happen after another explicit press on "Enter"');
  pause(2);
  disp('--- results of the 2nd part ---');

Instructions: either press "Enter" once on the 1st prompt, or comment out robot.keyPress and robot.keyRelease and press twice (or more).

Dev-iL
  • 23,742
  • 7
  • 57
  • 99
  • A bit of topic, but an alternative could be to use a dialog box. `message = sprintf('press ok'); uiwait(msgbox(message)); `. Mouse robot is not always funny, but in case you actually wants to wait for user interaction it is nice. – patrik Jan 05 '16 at 12:18
  • @patrik - As you said, your idea solves a slightly different problem (when mouse interaction is required/possible). If user interactions and code status updates happen in a separate window, one could have a figure with a "Next" button (like a custom `msgbox`) and setting the focus to the button, yet making the button disabled when it shouldn't be touchable... Though, I really don't know if this way you can discard unwanted keyboard events (when the button becomes touchable again)... Could you please explain how you mean to use the mouse robot in this case? (click the button on keyboard press?) – Dev-iL Jan 05 '16 at 12:47
  • My point is that the robot can still be used even if you leave the computer, or from the commandline with -nosplash option. Having a robot to move your mouse (to press ok) can not be trusted in the same way. I did not mean so much with my comment apart from that this was another way to solve the user interaction problem while still keeping the keyboard open for inputs. It was posted as a comment since it was not an answer to your question, but could still be useful for related problems. – patrik Jan 05 '16 at 14:23

1 Answers1

3

Using a timer to check that some minimal time has elapsed between the appearance of the next prompt and the "registered button press", allows determining whether the press may be considered valid. Thus, surrounding the 2nd prompt with the following loop seems to resolve this problem:

%% // 2nd prompt:
  tic; [~] = input('\nPress "Return" to start phase 2.\n','s');
  while toc < 0.002 %// 2ms , value may need adjustment based on the machine.
    [~] = input('','s');
  end
  disp('Please wait while computation is running...'); 
  // rest of code
Dev-iL
  • 23,742
  • 7
  • 57
  • 99