You don’t need to steal focus if you can just arrange for someone to give it to you


Commenter doesn't matter proposes a scenario where focus-stealing is necessary: There are two applications A and B, Application B exposes an interface, and Application A connects to application B via that interface, When some sort of even occurs in application B, it notifies application A, which wants to steal focus in order to interact with the user as a result of the event.

Actually, this is still not a situation where focus-stealing is necessary. Application B just needs to call Allow­Set­Foreground­Window on application A before it fires the event, so that when application A receives the event, it can display its dialog box or whatever. If the communication channel is via a window message, you can use Get­Window­Thread­Process­Id to get the process ID of application A. If the communication channel is COM, you can use Co­Allow­Set­Foreground­Window. If the communication channel is something else, well, then you'll have to use whatever mechanism works for your communication channel. (Obviously there must be at some point a place in the communication channel where it can figure out the identity of application A, since it needs to talk to application A to deliver the event in the first place.)

If you don't have access to the source code of application B, then you get to work with whoever designed the interface to convince them to add the necessary call for you.

But outright stealing the focus is the wrong thing to do, because it presumes that the user was interacting with application B when the event was fired. What if the event fired while application B was not the focus? Even if the event is a user interface event, like a mouse click, it's possible that the event will fire even though application B doesn't have the focus: Application B may receive the mouse click, and while application B decides what to do with it, the user switches to application C. Eventually, application B fires the event, but at this point the user is no longer working with application B, and transfering focus to application A would count as one of those evil focus-stealing situations.

Just because there's no good way to do something doesn't mean that you are automatically permitted to do it in a bad way.

Bonus chatter: Sometimes I wonder about the people who use the principle If I can't do something legally, I should be allowed to do it illegally, and then get indignant when they are caught.

"You got a parking ticket because you were parked in a handicapped space without a permit."

But all the regular parking spaces were taken. I had to park in a handicapped space; I had no other choice. You can't give me a ticket for that!

[Raymond is currently away; this message was pre-recorded.]

Comments (18)
  1. MarkJ says:

    I've been in this situation. The user asks my application A to do something. My application A calls on third-party application B to do processing (via COM). When application B finishes processing, the users want to see the results in application A. But application B insists on taking the focus while it processes, and does not expose any way to ask for the focus back. The vendor of application B is a large, unhelpful, organisation (not Microsoft, if it matters) and won't work with me because I only have a few dozen users. Focus-stealing starts to sound good.

  2. Rupert says:

    If there is never a good reason for stealing focus, why does Windows allow it at all? Even Visual Studio does it when it hits a breakpoint.

    Seriously – this drives everyone nuts and needs to be fixed. Can we start a petition or something? Who or what would Microsoft listen to on a subject like this?

  3. Joshua says:

    Wow a long chain of walls and ladders.

    @MarkJ: you can use the anti-focus stealing against them as well by arranging for your COM interop to be fired from a process that does not have the focus: Start new process, create window, give focus back to your main process, then trigger COM interop to big vendor's process. If they steal focus anyway, learn their technique and use the exact same one to steal back, that way your technique works until Microsoft gets around to breaking their technique and the transition is seamless.

  4. Ens says:

    Breakpoints can steal focus because the foreground process was being debugged (msdn.microsoft.com/…/ms632668(VS.85).aspx).  That's like if the firetruck stops in the handicapped parking space because it's close to the fire hydrant.

  5. poday says:

    @Ens: You're making the assumption that the foreground process was being debugged.  With VS2008 it's not uncommon for me to start debugging a long running non-interactive task and then switch over to a different program.  It's always annoying to be writing an email when Visual Studio suddenly grabs focus and I'm typing into my break point location.  I understand why it does it and I can't think of any better way to ensure I notice something I really want to notice but it doesn't make it any less annoying.

  6. PhilW says:

    Some seem to be missing a point Raymond often makes, which is that once you provide something like this it becomes pointless and easy to abuse. You could end up with more than one app on your desktop, each convinced that it is so special it must be on top, and the result of that is (potentially) constant focus stealing as the focus ping-pongs between each app leaving the user helpless, and probably blaming Microsoft too.

  7. AK says:

    This sort of thing happens to me every day:

    1. I'm in Outlook and come across a Word document as an attachment. I want to continue working with my emails but also want to open the document, preferably in the background, so I launch the attachment.
    2. Nothing happens immediately (my computer is pretty slow) so I click on another email to read.

    3. After a couple of seconds, the Word splash screen comes up and obscures my view.

    4. I click in Outlook to continue reading my email.

    5. Word opens its window in the foreground but has not loaded the document yet.

    6. I click in Outlook to continue reading my email.

    7. Word finishes loading the document and brings its window to the foreground.

    8. I click in Outlook to continue reading my email.

    Does this qualify as focus stealing, or is Windows just doing what I asked it to do (open a Word document)?

    Am I justified in wishing that Windows could handle this situation better or am I expecting the computer to read my mind?

  8. Andreas says:

    @AK: I wish I could write LOL but that's not funny anymore. I know your situation all too well.

    Browsers has solved this quite neat though, with tabs. Ctrl-click/middle click defaults to open a tab in the background and I can happily go on reading my current webpage until I'm ready to deal with the new now completely loaded page. I wish my interaction with Windows and all my applications could work in a similar way (maybe we just need some really fast computers with SSDs).

  9. Ooh says:

    @AK, Andreas: Wow, I never had this problem anymore since I switched to Win7 and Office 2010 and I almost forgot it! Now those were the bad old times…

  10. office focus says:

    Programs in a suit can "steal" focus from each other if they implemented a infrastructure for that.

  11. K says:

    I was about to point to Visual Studio 2010 for annoying focus stealing, but it seems other people were faster. Stealing focus during compilation when an error occurs, or when compilation finishes. Both highly irritating.

  12. Brian says:

    @office focus: Such a feature only needs the ability to "pass" focus, not the ability to "steal" focus.  That is, whatever window has focus has the right to give it to another window.  Of course, some programmer is bound to get a bonus by writing a library that can be used to cause whatever program has focus to pass it to another program.

  13. Random User 288934 says:

    @office focus: In this case, I suspect it is simpler than that. Outlook launched Word (in show the attachment). The remarks on AllowSetForegroundWindow() indicate that processes that were started by the current foreground process are permitted to set the foreground window (stealing focus).

    Word probably doesn't bother to check if it is currently in the foreground. Likely, it just attempts to set the foreground and assumes Windows will block it when appropriate.

  14. Rupert says:

    @poday Absolutely! Start debug, wait, wait some more, get bored, browse reddit, *focus steal*, type LOL in the code by accident, *face palm*

    @PhilW Fair point, but I've been waiting for Raymond to bring this issue up again so I could get his opinion.

    Fundamentally: Why should Windows allow focus stealing at all when it already provides FlashWindow and NotifyIcon?

  15. 10centmail.com says:

    The Windows shell has, since XP, a nice way of notifying the user without interrupting him. W7 is even better at allowing the app to send urgent notifications without interrupting. It is just not valid to interrupt, especially if that interruption includes a response popup.

  16. Two Cents says:

    I'd pay good money for a way to disable focus stealing forever and ever.

  17. Ens says:

    @poday

    Hmm, okay.  My workflow involves the Visual Studio remote debugger (VS2010) and I don't really recall encountering this, so I just assumed you were doing local debugging.  It's possible that it happens even in this scenario but I don't generally notice it.

  18. office focus says:

    @Two Cents: I'd pay good money for a way to disable focus stealing forever and ever.

    You also have to pay money to every suit of software, for not letting them implement a infrastructure for giving away focus to other apps in their suit.

    For example, VS & Office could agree on develop a focus sharing library, whatever windows os trying to is prevent.

Comments are closed.

Skip to main content