3 ms·

They are using a low-level hook to disable the expected behavior of a "get me out of here" key. They deserve all the stalls they can get. The reason it was so

They are using a low-level hook to disable the expected behavior of a "get me out of here" key. They deserve all the stalls they can get. The reason it was so complicated to get this behavior in the first place is because its heavily discouraged. Not to mention that calling SetWindowsHookEx will flag you as a keylogger in every antivirus snakeoil in existence.

speednoise 14y ago
So heavily discouraged that it was in this Microsoft sample code linked in the OP: http://msdn.microsoft.com/en-us/library/windows/desktop/ee416808%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/ee41...?
- revelation 14y ago
  That code is offered as part of the extensive documentation that Microsoft provides on its various frameworks. It by no means sanctions what still remains a terrible hack. A badly written hook could render a users system essentially unusable, and as I explained, its a very common heuristic for anti virus software. The point remains: the fact that you have to resort to globally hooking all input to break the expected behavior of a key can not possibly serve as an example for bad documentation or bad API design. It in fact proves the very opposite: you have to work very hard to break what users expect.
  - jamesmiller5 14y ago
    Considering that neither party, those who don't want to enable the windows key during full-screen and those who always depend on the windows key to function normally, is served without an unstable and error prone method it would seem the API is failing both parties in some cases. I think the author would agree with your last statement. By forcing the applications to handle this logic and break what some users expect the API isn't serving the users or developers well.
Pewpewarrows 14y ago
As any gamer in the last 15 years will tell you: the Windows key is the bane of our existence. It's a classic case of know your audience and customer, because if you've ever played a video game on Windows and are now developing one, you know that you should be disabling that key. You mentioned expected behavior, which is good to abide by. But there's also preventing accidents. Your users are imperfect. It's the reason big red buttons also get a follow-up confirmation dialog. Now, I'd definitely like to have a conversation about whether there should be a setting for disabling that override. But as for the default: it's pretty straightforward. When playing a fullscreen video game, the number of accidental occurrences of that button press far outweigh the number of intended uses. Pick your battles.
deleted 14y ago
[deleted]

speednoise 14y ago

So heavily discouraged that it was in this Microsoft sample code linked in the OP: http://msdn.microsoft.com/en-us/library/windows/desktop/ee416808%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/ee41...?

revelation 14y ago
That code is offered as part of the extensive documentation that Microsoft provides on its various frameworks. It by no means sanctions what still remains a terrible hack. A badly written hook could render a users system essentially unusable, and as I explained, its a very common heuristic for anti virus software. The point remains: the fact that you have to resort to globally hooking all input to break the expected behavior of a key can not possibly serve as an example for bad documentation or bad API design. It in fact proves the very opposite: you have to work very hard to break what users expect.
- jamesmiller5 14y ago
  Considering that neither party, those who don't want to enable the windows key during full-screen and those who always depend on the windows key to function normally, is served without an unstable and error prone method it would seem the API is failing both parties in some cases. I think the author would agree with your last statement. By forcing the applications to handle this logic and break what some users expect the API isn't serving the users or developers well.

Pewpewarrows 14y ago

As any gamer in the last 15 years will tell you: the Windows key is the bane of our existence. It's a classic case of know your audience and customer, because if you've ever played a video game on Windows and are now developing one, you know that you should be disabling that key. You mentioned expected behavior, which is good to abide by. But there's also preventing accidents. Your users are imperfect. It's the reason big red buttons also get a follow-up confirmation dialog. Now, I'd definitely like to have a conversation about whether there should be a setting for disabling that override. But as for the default: it's pretty straightforward. When playing a fullscreen video game, the number of accidental occurrences of that button press far outweigh the number of intended uses. Pick your battles.

deleted 14y ago

[deleted]