While I fully agree that there should be an option for it, Andrew's assumption is not actually an assumption - that's how Windows really works. The way Parallels handled the key combo up to beta6 actually planted the wrong assumption in some users that in Windows, ctrl-click works like in OS X, which is not the case.luz said:Please don't hard-code such assumptions into the solution. It might help some users, and will inevitably annoy others (e.g. those used to Ctrl-Click for context menus). Even worse is the new RC1assumption that when I press Alt, I would want AltGR (Ctrl+RightAlt). What if I want to press just Alt?
Please make it configurable (see http://forum.parallels.com/thread1853.html). Compared to the really complex virtualisation stuff you're doing so great with Parallels, this can't be that much of a problem to implement? A 8x8 matrix of flags...
The previous workaround of reassigning ctrl key to CMD key (which would be mapped to WIndows key inside Windows) using a Microsoft-supplied tool also have a problematic effect - Windows + (key) combo provides quick shortcuts to many of the Windows functions and being a frequent user of such combos as Win+E, Win+D, and Win+L, the 'sacrificing' of the Windows key had a crippling consequence, to a somewhat lesser extent than the 'missing' ctrl key.
I know that some users have grown to the ctrl-clicking to bring up context menu, and in case of laptop users it's necessary to have a key combo open to emulate the right mouse button. The current Parallels compromise aims to prevent disruption of any Windows-indigenous modifier keys while providing a slightly different alternative for emulating the right mouse button - ctrl-shift-click. I think this should be left as the default option even when the GA gets an option to assign what key combo should be considered as a right mouse button click.
Last edited: