Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Would be great if it also worked for the Windows key. #4

Open
GoogleCodeExporter opened this issue Mar 26, 2015 · 10 comments
Open

Would be great if it also worked for the Windows key. #4

GoogleCodeExporter opened this issue Mar 26, 2015 · 10 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. Switch to the Dvorak layout.
2. Run dvorak-qwerty.
3. Press Windows-E (which will produce a period (.), since you're in dvorak)
4. No explorer window is opened :-(. To do that, you have to press Windows-D.

What is the expected output? What do you see instead?
It would be nice if the Windows key also switch back to the qwerty layout.

What version of the product are you using? On what operating system?
Windows 7, newest version of dvorak-qwerty as of this post.

Please provide any additional information below.

Original issue reported on code.google.com by Anders.Aamodt on 22 Oct 2011 at 1:10

@GoogleCodeExporter
Copy link
Author

Hi Anders,

This is a good suggestion (and one I have thought of myself), but as I don't 
use Windows anymore I'm afraid I won't be making any changes to this code.  If 
you manage to fix it, feel free to send me a patch.

Original comment by [email protected] on 24 Oct 2011 at 5:12

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

THANKS for this awesorme tool...

I got the source and tried to handle the win key...  It seemed like everything 
worked but the shortcuts are all wrong...  I have attached the changes I made...

I think the problem might be in kDvorakToScancode - I didn't make any changes 
to it...  

Can you spare a few moments please - it is driving me crazy?

PS: The other dvorak-querty solution doesn't work for me because it messes up 
resharper shortcuts (the main reason I am using your tool)

Original comment by eibrahim on 4 Jul 2012 at 12:07

  • Added labels: ****
  • Removed labels: ****

Attachments:

@GoogleCodeExporter
Copy link
Author

Sorry, but I really have no ability to debug Windows code as I do not have any 
Windows machines anymore.  If you just want me to eyeball your code then could 
you please provide a diff instead of a full file?

Original comment by [email protected] on 31 Jul 2012 at 2:39

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

I've tried to do the same thing. Behaviour isn't broken for CTRL and ALT 
shortcuts, but with WIN key shortcuts it seems to trigger the hotkey using the 
dvorak layout in preference to qwerty. e.g. WIN+D should show the desktop, but 
it shows explorer instead. WIN+E, however, shows explorer correctly, presumably 
because WIN+"." is not a valid hotkey...?

I've taken a look at eibrahim's attacment and the diff is exactly the same as 
mine.

Some help would be great! Thanks again - this really is an awesome utility.

Original comment by [email protected] on 31 Jul 2012 at 3:36

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Oops. Sorry, the diff file didn't attach for some reason.

Original comment by [email protected] on 31 Jul 2012 at 3:39

  • Added labels: ****
  • Removed labels: ****

Attachments:

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

Oops, sorry, I missed comment #4 when I wrote comment #6.  Please disregard.  
(I subsequently deleted comment #6.)

It sounds to me like Windows is interpreting the win keys at a lower level of 
the event handling chain than where my tool hooks in.  Thus, only the win keys 
that aren't handled slip through and reach the tool, which then dutifully 
generates the appropriate fake event, which is then handled at the low level.

Unfortunately this probably means that the hook approach used by my code cannot 
remap the windows key at all.  It may be that there is another way to write the 
code that would hook in at a lower layer, but I don't know what that is and 
presumably it would involve a complete rewrite.  :/

There is actually a similar problem with my Linux tool -- it cannot remap 
OS-wide hotkeys.

Original comment by [email protected] on 31 Jul 2012 at 5:43

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

Oops. Man this thread is a mess. I can't believe I accidentally deleted my 
comment...sorry!

Anyway, thanks for the quick reply! 

I think your reasoning is exactly what I'm experiencing. I actually got the WIN 
key shortcuts to work with LowLevelKeyboardProc(), but using it broke the rest 
of the tool. With some futzing, I got it to work on the keyup part of the 
shortcut, but I still couldn't suppress the function of the original WIN key 
shortcut. For example, pressing WIN+D would first launch explorer (incorrect), 
then on release it would show the desktop (correct).

The solution, for me, was to reverse the functionality of the program. I've set 
my system's keyboard layout back to qwerty and I've inverted the conditional in 
DoKeyboardEvent() such that when no modifiers are held down the keystrokes are 
converted from qwerty to dvorak. When modifiers are held down (including the 
WIN key), the layout stays in qwerty mode. This seems to produce the least 
interference with the WIN key shortcuts.

Unfortunately, this isn't an ideal solution. For one thing, I know that I'll 
lose dvorak temporarily if I'm working inside a program running in 
Administrator mode.

I've attached my changes anyway. Hopefully someone will find them useful. I'd 
love to know if there's a better way to solve this.

Original comment by [email protected] on 31 Jul 2012 at 6:01

  • Added labels: ****
  • Removed labels: ****

Attachments:

@GoogleCodeExporter
Copy link
Author

Guh, I shudder at the thought of my horribly hacky code intercepting every 
keystroke.  :)  I suspect that approach will give you trouble, but I could be 
wrong.

Anyway, thanks for providing the patch.

Original comment by [email protected] on 31 Jul 2012 at 8:07

  • Added labels: ****
  • Removed labels: ****

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant