Uncaught error in keyboard allowed keys

Running PsychoPy v3.2.4, Builder.

If I type the name of a string variable into the allowed keys field of a keyboard component, instead of the name of a list variable, the consequences are as follows.

  • This change, and any subsequent changes to the program, are saved (the ‘date modified’ of the .psyexp file is updated).
  • However, when the program is run, the ‘_lastrun.py’ file is not updated (the ‘date modified’ of this file remains the same as before) and the version of the program that runs is an old version corresponding to the ‘_lastrun.py’ file.
  • If I make a copy of the .psyexp file and run it from a folder where the ‘_lastrun.py’ file is not present, the program fails to run. It crashes immediately, without prompting for experiment info, and gives the following error message:

C:\Program Files\PsychoPy3\python.exe: can’t open file ‘D:\Users.…\IAT_lastrun.py’: [Errno 2] No such file or directory

The documentation for the keyboard component does state that the allowed keys field should contain the name of a list variable. However, I think this error should be caught because an inexperienced user would tend to assume that this field will accept the name of a string variable, for example a string called ‘correct’ which has been read from a conditions file. Also, it requires some basic knowledge of coding to use this field correctly, for which some users will require guidance. For example, I had to first place my string called ‘correct’ inside a list variable, using a code component:

allowed_response = [correct]

Apologies, I’ve just installed v2020.1.3 and I can see that the problem has already been resolved. The allowed keys field of a keyboard component now accepts the name of a string variable.

Interestingly, I have subsequently seen a similar pattern of behaviour associated with an uncaught error (i.e. the ‘_lastrun.py’ file fails to update and any changes made to the program do not show up when running the program) in v2020.1.3, this time caused by a different event. In this case, the event was not a change made to the program, but the act of moving the project folder into the Windows 10 recycle bin and then retrieving it. The solution was to rename the Builder program, either using ‘Save As’, or just highlighting and changing the name of the file in Windows Explorer.

The Builder program had somehow become self-contained, so that it ran even when all associated Excel conditions files and image files were deleted, and even when the ‘_lastrun.py’ file was deleted. Renaming the program freed it from its hermetic bubble. Changing its name back to the old name put it back into the bubble. All perfectly repeatable.

So, if anybody ever notices that changes they have made to their Builder program are not shown when it runs and there is no error message, it may be worth checking whether the ‘_lastrun.py’ file is being updated. If it is not being updated, then renaming the program may solve the problem.

1 Like