Page MenuHome

Shift key stays pressed in Ctrl+Shift+Alt combination
Closed, ResolvedPublic


When pressing Ctrl+Shift+Alt, the Shift key stays in a pressed state. This seems to occur in every type of window. This bug may have some relation with this one :
To get out of this state the user must press Shift again. This brings many confusing situations.

System : Windows Vista 64 on a 32 bit machine (also occured on Windows Vista 32 on another 32 bit machine)
rev : 35116, It also occured at rev. 34116 (yes exactly 10 000 rev. ago! but maybe older)

Sytem-info is attached.

Steps to reproduce :
-Open Blender
-Press simultaneously Ctrl+Shift+Alt keys in any window
-Then in the 3d view, middle click and move the mouse to rotate the view
-Notice that the view is not rotating but panning (Shift again to get out of this state)

Also Notice in System-info that returns -UNKNOWN- instead of the revision number. This occurs since at least 34995.



Event Timeline

But it is really hard to replicate. I was able to do it twice so it will be hard to debug.
Similar bug is with Ctrl+Shift+Alt+Win

I will look into this.

Ok, I forgot to mention something. I work on a laptop with a usb keyboard. With that setup the bug occurs 100% of the time. If you have one close, you could try to see if you get a better ratio. I tried it with the laptop keyboards and it is still possible to do it on both systems, but at a lower ratio. It seems to be easier to replicate with the slower computer. Here are the specs of my computers to give you an idea: core 2 duo 2GHz, Pentium dual cpu 1.46GHz

To facilitate replication, you can do Ctrl+Shift+Alt directly in the 3d view. And sometimes it is Ctrl that stays pressed and keep zoooming. But Alt never did it, at least it never made the view point to snap.

It seems to be Windows related problem. Apparently GHOST sometimes doesn't receive 'up' command from one of the three keys. I will try to fix it.

Alexander: this would be very welcome. I heard from Nathan Letwory that the code here is quite complex though... windows seems to have weird methods for modifiers.

Found the problem. There is two possible solutions. Tomorrow I will test second one and compare and then I will send a patch. BTW, char for 'ascii' soon will be very limited for UTF8 & international keyboards.

I attached the patched.
PeekMessage 'ate' WM_SYSKEYDOWN & WM_SYSKEYUP messages which were in between WM_CHAR < WM_SYSDEADCHAR.
Dunno, removing messages is not really necessary as commands like WM_CHAR are skipped anyway.
I had idea to use ToAsciiEx, but then Blender never has proper Keyboard status.

Easier way to test this bug:
Open Task Manager
Right click on Blender
->Set Priority -> Low
-> Set Affinity -> to only one CPU
Try to press Ctrl + Shift + Alt simultaneously several times

Anyway keyMsg.wParam returns UTF-16. Ideally it should be converted into UTF 8 with 4 char array with WideCharToMultiByte, but GHOST messages do not support UTF8 yet. Therefore ascii should be clipped to be compatible with UTF-8.

Assigning to myself to review and commit.

Looks very much like this is essentially a duplicate of [#25476]. I'm as such marking this as duplicate, but will use the attached patch still from this one though.

(closing now as duplicate, will be changed to fixed when patch is in).

Applied patch from in r35283.