Assigned to Nathan.

First of all; the 'emulate 3 button mouse' emulates the middle-mouse button, which is for view manupilation.
Alt+Shift+LMB translates the view here. How do you drag an object with it?

I tested 'emulate 3 button mouse' here in OSX, with 2.55 release and latest svn. Nothing is bad here.
- Please confirm you have official build from www.blender.org
- Test an older version as well, including the last 2.49 release
http://download.blender.org/release/
- Tell us if this ever worked for you before? If so, try the same blender version again, to rule out something else changed.

I'm unable to redo this on my laptop with "emulate 3 button mouse" and fast pressing of alt and shift in any order, or simultanously. I haven't been able to reproduce on my desktop either :/

Assigning to Andrea so she can test also for a while.

Andrea, if you can't reproduce either, feel free to close.

My mistake. I meant "tranlate view" of course.
I made a screencast to demo that behaviour
http://www.youtube.com/watch?v=yqxkrAfCc8I
Go to 00:58 to see that the same combination works different.
"translate view" becomes "rotate view".
Used version is r32738.

I watched the video three times, but the information is extremely hard to interpret. The overlay window doesn't show key-releases.

The issue is not that we don't believe you, the issue is that we need to know how to redo it.
Start Blender in a Command Prompt, with debug on: blender.exe -d

After initial loads of prints, it will mostly print events that come in, and operators that get executed.
Play with holding and pressing Shift and Alt keys, and check if each press and release is printed correctly.

This is what I get from command promt:

pass on evt 1 val 2
bpy.ops.view3d.move()
pass on evt 213 val 2
pass on evt 217 val 2
pass on evt 213 val 1
pass on evt 217 val 1
pass on evt 1 val 1
handle evt 2 win 12 op VIEW3D_OT_move
pass on evt 1 val 2
bpy.ops.view3d.move()
pass on evt 213 val 2
pass on evt 217 val 2
pass on evt 213 val 1
pass on evt 217 val 1
pass on evt 1 val 1
handle evt 2 win 12 op VIEW3D_OT_move
pass on evt 1 val 2
bpy.ops.view3d.move()
pass on evt 213 val 2
pass on evt 217 val 2
pass on evt 213 val 1
pass on evt 1 val 1
handle evt 2 win 12 op VIEW3D_OT_rotate

I don't need these prints. I need to know if you can investigate yourself there what goes on:

"Play with holding and pressing Shift and Alt keys, and check if each press and release is printed correctly."

Sofar nobody I asked could reproduce your report.

If I press Shift and then Alt, I see feedback immediately.
But when I press first Alt and then Shift almost immediately, the result is that feedback for Alt is immediate but feedback for Shift comes about 1/3 second late.

Thanks! Now that's strange... and it happens on all three of your systems?
Is there some program running catching this shortcut?

Alt+Shift is a shortcut key to switch between keyboard layouts on Windows, perhaps it is somehow due to that. You could test if turning it off helps, instructions here:
http://wiki.squeak.org/squeak/3339

I checked keyboard switching possibility - all 3 machines had this feature turned off and all have only 1 keyboard layout installed.

I also tried 2.49b and 2.54 on these machines and it was not possible to reproduce with these versions.

Since we cannot redo your problem, you have to be very exact with your responses.
That means I expected you:

- tested only official builds from blender.org
- the 2.55 version, when running as "blender.exe -d", an ALT+SHIFT press shows 0.3 second delay for shift
- the 2.54 version, when running "blender.exe -d", shows immediate response to shift

If that's true, then check if these versions have been installed differently, use the zip versions from blender.org for example, don't use any custom keymaps, and only the default as available with "File -> factory settings".

Your last comment is exactly what my case is.
Since now, I used installer versions for 2.55 and zip-versions for 2.54.
Now I tried zip-version for 2.55 and the behavior is the same as in installer version.

Today I got noname laptop computer with windows 7 32-bit. First, I was unable to reproduce the same result myself on that computer.
But, when I tried the alt+shift key sequence ultimately-ultimately fast, I got the same 0.3 second delay between real shift keypress and feedback in "blender -d"

Hmm, do you have any of the accessibility features on?

Accessibility features are turned off on all Windows machines.

Now I tried official 2.55 on OS X and it was not possible to reproduce with it.

Now I tried official 2.55 on 64-bit linux and it was not possible to reproduce.
So far looks like the problem applies to windows only.

Nils: the issue clearly points at how events get handled on OS level, in Blender we don't have code that messes with such cases. We can only hope you (or someone) is able to find a way in your windows configuration that disables the delay. I'll keep an eye at this topic when we do testing, or get related reports. If you post here, I'll reply as well!

Closing issue now.

Added a duplicate

I have the same problem. My system is Windows xp sp 2 and Blender 2.55 official from Blender.org. When i press alt and holding alt press shift it works good, and if i press shift and holding shift press alt it is working good, but if i press alt and shift together it is not works. But in Blender 2.53 everithing okay.

It's important to be extremely clear for us, since no developer has been able to reproduce.
- did you test 2.53 and 2.55 at the same moment, just now? Remembering it was working is not good info :)
- was this 2.53 also a release from blender.org?
- then also try 2.54 http://download.blender.org/release/

I have just downloaded Blender 2.54, and tested Blender 2.53, 2.54, and 2.55 just 2 minutes ago :) Pan view in Blender 2.53 , 2,54 is normal and in Blender 2.55 if press shift and alt together it is not working. I am sure 100 %. All builds are from Blender .org.

Thanks for the quick test! Here's another one, to make sure what's exactly wrong:

- start blender, duplicate standard cube a couple of times and put them on same location
- press alt+shift+RMB , that should open a menu to select

Check if this alt+shift combo has same problems as for view ? Maybe enable/disable the "emulate 3 button" option.

in Blender 2.55 if press alt+shift+RMB it is select one of cubes, but it does not opens select menu. In Blender 2.54 and Blender 2.53 is everithing alright with it. If disable emulate 3 button it is also not opens select menu (Blender 2.55)

make sure you're in solid display mode, with several cubes on the same location where you click.

also don't say "everything all right" that's not clear :) be descriptive and exact.

Maybe the developers have too modern computers to reproduce. It somehow depends on the system speed.
My oldest computer is 2-year old AMD Athlon 1 GHz. with cheapest motherboards and other components that time. The delay on that machine is the biggest.
On newer and faster systems, it is really hard or nearly impossible to reproduce.

Okay. I have duplicated cubes with shift+d and they are in the same location. In Blender 2.55 with shift+alt+rmb on cubes it selects one of cubes. In Blender 2.53 with shift+alt+rmb on cubes it opens select menu. I am in standart display mode , not change anything.

Mihail: thanks for all testing, but we're still clueless here. The most important issue remains: how can we redo it? Try other systems if you have them around, and keep checking for when the error is precisely happening. Check what I discussed with Nils, with prints in terminal. That way you can see what keys are registered when. It can be that you press the mouse button *before* the modifier key is being send to blender. Press keys slower, press alt+shift, or shift+alt first, and so on.

I am not sure if this is relevant, but I notice that if I disable the emulate 3 mouse buttons, then the objects can be dragged using Alt+Shift+LMB only if we initiate the drag with the mouse on the object's axes. If we start the drag on any other point on the object's body, it fails. As opposed to the right-click drag, which gets started anywhere.

We've deducted that it's related to keyboards with an "AltGr" key. If you configure your keyboard (in OS) to use regular american layouts it works fine.
There's code in Blender that might cause this, we'll check on it.

You mean to change in language panel to English (USA) ? I have english and russian, i have tried to remove russian, to remove shortcuts that switch languages (that was ctrl+shift), to remove language panel. It is not helps.

What I've seen is that rightalt+shift doesn't work on keylayouts use AltGr to create characters that are not accessible through normal typing or with shift.

When an AltGr-enabled layout is found, there is special handling of the right alt key (AltGr), since on such a layout, pressing right alt results in the OS sending a Ctrl down as well, so a Ctrl Up is pushed as an extra.

I'll try working on this soon, so I assign to myself.

If someone is interested in looking for a solution, the relevant code is in intern/ghost/intern/GHOST_SystemWin32.cpp and its corresponding header.

I think I've finally nailed this in r33928.

I've uploaded new builds to graphicall: http://www.letworyinteractive.com/b/2010/12/blender-2-5-r33928/

Please test and report back. Preferably with the non-installer version.

I got reports from other user that this now works. Closing.

Today I tried 2.56 and the problem is still there.
I tried on Intel Celeron 1,7GHz Windows XP SP3, US keyboard layout activated.

Applied patch from [#26208] in r35283. This works now very nicely IMO.