| Reference | Downloads | Github

Non-ascii character in keyList for event.getKeys

Hi there,

I have a problem using non-ascii characters (in my case German umlauts) as response keys specificly if I enter them into the keyList parameter of the event.getKeys function (PsychoPy version 1.84).

There is no error unless the target umlaut char (i.e. u'ä') is pressed and therefore contained in the keyList and only if I request a timestamp:

  File "***\", line 21, in <module>
    for i in range(trainingTrials): Trial(window, (random.choice(trainingShapes),), shock=False, fixationCross=fixationCross, ratingTexts=ratingTexts, textStim=text, feedback=True, log=False)
  File "***\", line 340, in Trial
    (key, rt) = evaluateRating(event.getKeys(keyList=[u'\xe4'], timeStamped=clock))
  File "***\psychopy-1.84.2-py2.7.egg\psychopy\", line 345, in getKeys
    relTuple = [filter(None, (k[0], modifiers and modifiers_dict(k[1]) or None, k[2] - timeBaseDiff)) for k in targets]
IndexError: tuple index out of range```

It seems like tuple entries with umlaut keys are dropped at some point.

***Update***: I tried to work around by not providing a `keyList` attribute and filtering the result manually but this also leads to the error. It does work, however, if I call with `timeStamped=False` (but I need the RT). So it definitely has to do with `(umlautKey, time)` pairs.

Thanks for your help!

Hi Mario,

Firstly, are you sure that the keyname is “ä”? Keep in mind that the name of a keypress is separate from the appearance of the character it generates. Run the keyNameFinder demo to check.

This demo did have a bug that should be fixed in upcoming versions, so just in case it’s not released yet, here’s the fixed version:

keyNameFinder.psyexp (7.9 KB)

Run this to confirm what the name of the key press is, and be aware that it can be different for different machines.

If it’s not a simple case of giving the wrong name for a key press, we’ll need a simple code example (preferably a Minimal Working Example) demonstrating the problem to better help. Based on what’s given here I personally wouldn’t be able to offer suggestions yet.

Hi Daniel,

thank you for your quick reply. As mentioned above, the error only occurs under certain circumstances and can therefore not be due to a wrong keyname. Nevertheless, I checked with the keyNameFinder and can confirm that the keyname is ‘ä’.

As a minimal working example, I modified the keyNameFinder (8.1 KB) to replicate the error:
I just replaced the first line of the code for each frame with:

keys_RT = event.getKeys(timeStamped=True) #keys, rts = event.getKeys(timeStamped=True) produces an error if event.getKeys(timeStamped=True) == None
if keys_RT:
    keys = [item[0] for item in keys_RT]

For you to replicate the error, you will have to set your keyboard to German.
The following keys will then cause the experiment to crash: 'semicolon', 'apostrophe', 'bracketleft', or 'minus'.

The error message is the same as mentioned in my original post:

I’ve been able to reproduce the problem (though the file you uploaded doesn’t match the code you posted, maybe you posted before saving the experiment. It would be good to edit that post and attach an updated experiment file, here’s something that reproduces the error, for others who may want to tinker).

keyNameFinder (copy).psyexp (8.1 KB)

It looks like a bug in, but I’m not going to be able to look at it further today. Will post back when I’ve had a chance.

I believe I have a fix that will hopefully not break anything else.

Go to the line of the error (line 348 in your version) in, and change the number 2 to a -1, like this:

return [filter(None, (k[0], modifiers and modifiers_dict(k[1]) or None, k[-1])) for k in targets]

The problem seems to be that the key press event will get passed around to different functions if it can’t be handled properly by one of them, and one of the functions puts a 3 member tuple (keyName, areThereModifierKeys, timeStamp) in the _keyBuffer, while the others put 2 member tuples (keyName, timeStamp). So when the code tries to access the third member of a tuple with two items, it obviously throws an error.

This quick fix makes it so that we get the last member of the tuple (k[-1]), which should always be the timestamp, and it doesn’t matter if the tuple has 2 or 3 elements.

A bigger question (which I will hopefully be able to post to github @jon , sorry, a little busy at the moment), is whether all of these functions (_onPygletText, _onPygletKey) are supposed to be putting the three-member tuples in the _keyBuffer.

But Mario hopefully this solves your problem.

1 Like

I ended up creating a quick pull request suggesting this bug fix: