Pressing a registered hotkey gives you the foreground activation love


One category of application that people complained about is the application launcher which keys off a hotkey and doesn't get the foreground love.

Well, except that windows with registered hotkeys do get the foreground love.

After you call the RegisterHotKey function to register a hotkey, the window manager will send you a WM_HOTKEY message when the user presses that hotkey, and along with it, you will get the foreground love. If you call SetForegroundWindow from inside your hotkey handler, the foreground window will change according to your instructions.

A special administrator-only list of programs which are exempt from SetForegroundWindow rules would just be adding another round to the game of walls and ladders. All that'll happen is that programs, when they install, will place themselves in the Exempt from the normal rules list, and you're back where you started.

"Oh no, I'll super-protect that registry key so that the only way to add an entry to it requires a human being to respond to a dialog box confirming that the entry is being added."

Well, for one thing, that doesn't actually stop installers with administrator privilege, since they can just remove the super-protection and update the key anyway. (Administrator privilege is like that.) And even if you somehow manage to super-protect the setting (how? beats me), the next stage is application vendors (or system administrators attempting to deploy the application across their company) asking for a programmatic way to add their program to your super-protected list of exemptions. And then you're back to where you were.

Comments (24)
  1. Ben Voigt [C++ MVP] says:

    This strikes me as a solved problem. We already have code signing tools. What we’re missing is that oh-so-small leap from “signed by the developer” to “signed by the administrator”. No one can add the special magic without the admin’s private key (and passphrase if he chose to protect that key). Programmatic access — solved (but the app must use a certificate co-signed by the admin or it doesn’t enable the restricted behavior).

    The only catch is that you must lie to the app and prevent it from asking “Do I have advanced rights enabled”, otherwise every two-bit developer will demand that you sign their app as part of the install process.  (But better yet just make Microsoft products install without the signature and thus set the expectation high for third-party developers… much of the problem with software not installing and running in a limited account is that the role models don’t)

    [All somebody has to do is find a program which is already signed for SetForegroundWindow, inject a thread, and call SetForegroundWindow from there. So once you have one program which is signed for SetForegroundWindow (e.g. Explorer), all programs are effectively signed for SetForegroundWindow. -Raymond]
  2. Yuhong Bao says:

    “A special administrator-only list of programs which are exempt from SetForegroundWindow rules would just be adding another round to the game of walls and ladders.”

    That began when SetActiveWindow was crippled and SetForegroundWindow was added in Win32.

    [I already covered this last year and you were here then, so you know that I already covered this last year, so what’s your point? -Raymond]
  3. parkrrrr says:

    "All somebody has to do is find a program which is already signed for SetForegroundWindow, inject a thread, and call SetForegroundWindow from there."

    Of course, if you can inject a thread, you can get the current foreground process to call AllowSetForegroundWindow for you, too.  Not that I’ve ever done that or anything.

  4. Neil says:

    Just turn foreground activation off, and when people complain, say it was for feature parity with Linux.

  5. Keithius says:

    The game of "walls and ladders" is one that sometimes keeps me up at night.

    People just need to understand there are ALWAYS compromises. You can’t please everybody all of the time, after all!

  6. someone else says:

    @Anonymous Coward: You are assuming that the user is a programmer. Knowing the language. With access to the appropriate compiler.

    Now you explain that to grandma™.

  7. NOS says:

    "@Anonymous Coward: You are assuming that the user is a programmer. Knowing the language. With access to the appropriate compiler.

    Now you explain that to grandma™."

    Well, if the someone can patch code I assume they can also create an automated package/installer for it and all grandma has to do is double click it.

    F/OSS is designed to help developers, yes, users, not necessarily.

  8. Mick says:

    How does SwitchToThisWindow fit into the picture? It’s documented nowadays.

  9. Doug says:

    The amusing thing about this set of rules about foreground taking, etc, is that there are very valid circumstances for doing this.  Not in the "home user" type environment, but in the "workflow" type environment.  Here you have a suite of applications, not necessarily integrated well, and you have valid business workflow reasons to be adjusting which application is on top.

    There does not exist a set of rules which will satisfy all environments and requirements.

  10. Dean Harding says:

    Hehe, this is classic "Raymond"! Everybody starts to say "Windows should OBVIOUSLY be doing X". After enough people chime in with "Windows is dumb because it doesn’t do X" and BAM! Raymond comes back with "Uh, Windows already does X."

  11. steveg says:

    @Anonymous Coward et al: open source let’s you change stuff by code or download.

    Only if you can be bothered, and only until the next update undoes your work. At some point you give up patching stuff and just accept it Out Of The Box(tm). Also, that theory is fine at home, but when you work in a a tightly controlled environment, it becomes less feasible (but not impossible).

    Approximately on the topic: Hubris is amazingly common in IT (presumably other fields, I don’t really know): This new app/website/feature/etc is The Most Important Thing Ever. People seem to, in general, suffer from a lack of perspective about where their app/website/feature/etc fits into the greater whole. Generally, and it’s sad to say, you’re just not that important.

  12. Yuhong Bao says:

    [I already covered this last year and you were here then, so you know that I already covered this last year, so what’s your point? -Raymond]

    That last year article was about *Get*ForegroundWindow and *Get*ActiveWindow, not *Set*ActiveWindow and *Set*ForegroundWindow.

    [The same story clearly applies to Get as well as Set. I can’t believe I had to write that. You got distracted by the example and missed the point of the article. Perhaps I shouldn’t have given an example. -Raymond]
  13. Anonymous Coward says:

    All these stories about applications fighting over your desktop, screwing you in the process are actually one of the best arguments for open source I’ve ever heard. So you pop in my face eh? *snip* No you don’t, not anymore.

  14. Technage says:

    All a program really has to do is sendkey("%${TAB}") (I chose ALT+SHIFT+Tab{I think %$ are right I am not looking at the code} because then you scroll from the back side and don’t have to deal with the crazy push it twice to get out beyond the two most recent apps problem) until you notice the desired form got focus, but that’s my hack fu and when you sleep for 5ms between each sendkey you don’t really even notice it happen.  Please don’t break my program! :P

  15. Ray Trent says:

    Perhaps I wasn’t clear in that last post, but a hotkey (button) was just one example of a legitimate user-configured application launcher.

    Even there, I was mostly talking about those magic buttons sitting up at the top of your laptop keyboard that aren’t even always/usually reported to the OS as keystrokes of any kind, much less registered hotkeys.

    In my case, in addition to the above, we have user-configurable TouchPad buttons, tap zones, and/or "press here to temporarily convert your TouchPad into a bunch of lit-up application launcher buttons" with app launcher functionality.

    None of which have anything even remotely to do with hotkeys, registered or otherwise.

    Now, in theory, I could call RegisterHotKey and then inject that key in using SendInput (assuming that even works, particularly if an elevated app has the keyboard focus). However, whatever hotkey I select to register might be one that the user already has defined for themselves. That’s pretty baroque, though.

    SwitchToThisWindow works a lot better (at least for now :-).

  16. Nick says:

    I too would love to hear the life story of the previously undocumented function SwitchToThisWindow — how/why it came about, and how it finally ended up becoming a documented and supported method of bypassing all the rules put forth by the other window order functions.

    It seems like it might have been a case of “So many bloody apps depend on this undocumented functionality that we may as well just document it to prevent mass breakage.”  More interesting though would by why it was written in the first place.  Any insight Raymond?

    [It shouldn’t bypass anything. It’s internally just a wrapper around SetForegroundWindow. Rats, I fell into the trap of people using comments as a way to bypass the suggestion box. -Raymond]
  17. Lev says:

    "Oh no, I’ll super-protect that registry key so that the only way to add an entry to it requires a human being to respond to a dialog box confirming that the entry is being added."

    A registry key protected by CAPTCHAs?

  18. 640k says:

    win98: MySetForegroundWindow: 1 line of code

    w2k/xp: MySetForegroundWindow: 20 lines of code

    vista: MySetForegroundWindow: 40 lines of code

    win7: ?

  19. Perley says:

    What I would love is a way to prevent some of that "foreground love".  I hate it when I start a program, switch to another program while that one is loading, and, right in the middle of doing something, the program that I started the load for jumps to the foreground.  So far no solution……

  20. Mark (The other Mark) says:

    A registry key protected by CAPTCHAs?

    This will have me chuckling the rest of the day- Thank you!

  21. someone else says:

    @Perley: Right, that kind of behaviour should be reserved for instant messengers. Nothing like a steamy conversion with you SO, and just as you are typing something really outrageous, you grandma comes in and grabs focus. Which you only notice *after* sending.

    Same for passwords.

  22. Miral says:

    That’s why I said in the previous post that it should be a blacklist, not a whitelist.  Let any program have the foreground love by default, but allow the user to blacklist the suckers if they abuse it.

    And yes, a program could explicitly remove itself from the blacklist, but it seems less likely to me that this would occur in the wild, except for programs that are being intentionally evil.  And those could be locked out if there was an administrative-level blacklist in addition to the user-level blacklist — the app running as limited-user (or unelevated admin) wouldn’t be able to de-blacklist itself from the admin blacklist (although its installer could).

  23. DWalker says:

    @steveg:  PLEASE stop putting an apostrophe in the word "lets".  Thank you!

  24. Stecthait says:

    For thou art so possess’d with murderous hate

    That ‘gainst thyself thou stick’st not to conspire.

Comments are closed.