Page MenuHome

Pressing V key in user preferences is recognized as Ctrl+V
Closed, InvalidPublicTO DO


System Information

Blender Version
Broken: blender-2.70-90db85a-win649
Worked: blender-2.70-85398de-win64

Short description of error
Pressing V key in user preferences is recognized as Ctrl+V
(no, my keyboard is not broken ;) )

Exact steps for others to reproduce the error

  1. Add any text to the clipboard
  2. Start blender
  3. Press Ctrl+Alt+U to open user preferences.
  4. Click on the "File" tab
  5. Hover the mouse over the first textbox (labelled "Fonts:")
  6. Press V key. The text from the clipboard gets inserted even though Ctrl key isn't held down.

You can also enter the textbox, and V key pastes from clipboard. Pressing Ctrl a single time solves this.

I guess Ctrl key release gets lost while holding it down when opening another window, so Blender thinks it's still down.

Event Timeline

Willi (willi) raised the priority of this task from to 90.
Willi (willi) updated the task description. (Show Details)
Willi (willi) added a project: BF Blender.
Willi (willi) edited a custom field.
Willi (willi) added a subscriber: Willi (willi).
Willi (willi) added a comment.EditedMay 23 2014, 12:48 PM

Hmm... physically installed Kubuntu (outside VM) just to test this.... not reproducable.
However checked again on Win7/64, and also a problem in VM on WinXP (32 bit). Though, a minor one.

Bastien Montagne (mont29) lowered the priority of this task from 90 to Normal.May 24 2014, 4:43 PM
Willi (willi) added a comment.EditedMay 24 2014, 7:11 PM

It seems (and I hope) this is a closely related problem: While rendering (on CPU), I opened the user preferences, and on the "Input" tab, I entered the word "screen" in the search textbox, but it only displayed "scren" (one e missing). Ok, a typo I thought first, so I did it again, but if you're typing fast, one e always gets lost (but not the "n" that comes next!). It happens only in Blender, and only if the CPU is busy. It does not happen during the render preperation phase where only 1 of 4 cores is busy.
EDIT: For better reproducability: It's sufficient to type "reen". Timing is critical in this case, therefore the hint.

...Addition: [EDIT: comment deleted]

I will test on Kubuntu....... EDIT: Same problem on Kubuntu, not only Windows.

Willi (willi) added a comment.EditedMay 24 2014, 7:23 PM

Sorry for another addition, but after clocking down my CPU to 800 MHz the description has to be reworded:
If you type "r", the search starts. If you then type "een" while Blender searches the shortcuts, and if the "n" has been typed before the search has finished, one "e" gets lost.

So, this has nothing to do with CPU occupation in general. It's just that the search takes longer with a busy CPU. This rises the probability that you're typing the "n" before the first search returns.

Video (incl Audio):
You can hear me typing 4 keys.

In this respect, it now turns out the problem is not related to this task. Sorry for that!

Campbell Barton (campbellbarton) changed the task status from Unknown Status to Resolved.May 26 2014, 10:13 AM

committed workaround for win32 rB34862b5b57a6ddaa8989ad0c693450de92666af9

Campbell Barton (campbellbarton) changed the task status from Resolved to Unknown Status.Mar 3 2015, 2:39 AM

Commit was reverted... this is still a problem. added to TODO (