Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Supported by

Keyboard stops responding

Hello everyone!

We are running an experiment in OpenSesame for a group of children all at the same time. In each session, a few keyboards (3, 4 or 5 even) suddenly stop working. If we exit OpenSesame, we can see that the keyboards are in fact working, but going back into the experiment, they are not responsive. If we stop the experiment and run it again, the issue is no longer there. This has happened at different points in the experiment and on different computers (some with wireless keyboards and some with normal keyboards). Has anyone come across this before? Any idea of why this might happen?

Comments

  • Hi Simona,

    The first thing that comes to mind is that some application running in the background might steal the focus on OpenSesame, and hence OpenSesame no longer receives keyboard events. If that's true, then switching away from the OpenSesame window (Alt+Tab) and switching back to it should solve the issue. Does that work?

    Cheers!

    Sebastiaan

  • Hi Sebastiaan,

    Thank you for your quick reply. We tried that and it doesn't work. When we switch away from the OpenSesame window (using Alt + Esc, or pressing on the Windows key), we can see that the keyboard works fine, but when we switch back to OpenSesame, the keyboard is still unresponsive (the Esc key on its own doesn't work either).

    Best,

    Simona

  • Hi Simona,

    In that case, another possibility that comes to mind is that the experiment uses an unconventional response device (maybe a joystick or mouse scrolling?) and that this sometimes results in so many response events that the event buffer overflows. And then everything stops working. This can be very unpredictable, because it tends to depend on what the participant exactly does at specific points in the experiment.

    If this is the case, this would be need to be fixed in the experiment. Could you attach the experiment here so I can take a look?

    Cheers!

    Sebastiaan

  • Hi Sebastiaan,

    Ahhh I see, that might be it! I don't think the mouse scroll button has been deactivated (they only use the mouse and keyboard, no joystick). Do you think by simply deactivating the mouse scroll button that issue would be resolved? Please find attached a copy of our experiment.

    Thank you!!!

    Simona


  • I think you uploaded the wrong experiment ;-)

  • Hi guys, a bit late but I would still like to chime in. With problems like these, it doesn't help that they can't easily be reproduced. I have yet to encounter the freeze as described above myself. The mouse scroll button is not actively used, but not disabled either, so this may be a factor. I have to find a way to exclude these events from the pygame event bus then. I did take care of flushing the events in the bus frequently, so I assumed that would empty the buffer once in a while.

    I think the experiment is too large to update here (9 MB), so I below is a OneDrive link through which the experiment can be downloaded.

    https://1drv.ms/u/s!AuZ-4EUKx9prlY4inNi_-e-ZDvyJJA?e=nI8z63

  • Hi Daniel,

    The experiment is too complex for me to understand. But to answer this question:

    I have to find a way to exclude these events from the pygame event bus then.

    You can control that with the pygame.event.set_blocked(), pygame.event.get_blocked(), and pygame.event.set_allowed() functions.

    By default, the mouse-motion events are blocked, but the rest is not. So if there's a very loose scroll button, I can imagine that this would fill up the event buffer.

    Cheers!

    Sebastiaan

Sign In or Register to comment.