Foreground activation permission is like love: You can’t steal it, it has to be given to you

This is the blog entry that acted as the inspiration for the last topic in my 200 PDC talk.

When somebody launches a second copy of your single-instance program, you usually want the second copy to send its command line to the first instance (and deal with the current directory somehow), and then you want the first instance to come to the foreground. But a common problem people run into is that when the first instance calls SetForegroundWindow, it fails.

The problem with this design is that as far as the window manager is concerned, what happened is that the first instance received a message and then decided to steal foreground. That message wasn't an input message, so the window manager sees no reason for the first instance to have any right to take the foreground. There is no evidence that the first instance is coming to the foreground in response to some user action.

There are a variety of ways of addressing this problem. The easiest way is simply to have the second instance make the call to SetForegroundWindow. The second program has permission to take the foreground because you just launched it. And if a program can take the foreground, it can also give it away, in this case, by setting the first program as the foreground window.

Another way to do this is to have the second program call the AllowSetForegroundWindow function with the process ID of the first program before it sends the magic message. The AllowSetForegroundWindow function lets a program say to the window manager, "It's okay; he's with me." And then when the first program finally gets around to calling SetForegroundWindow, the window manager says, "Oh, this guy's okay. That other program vouched for him."

If you are transferring foreground activation to a COM server, you can use the corresponding COM function CoAllowSetForegroundWindow.

In all cases, note that you can't give away something that's not yours. If you don't have permission to take foreground, then calling AllowSetForegroundWindow (or one of its moral equivalents) will have no effect: You just told the window manager, "It's okay; he's with me," and the window manager replied, "Who the hell are you?"

Pre-emptive snarky comment: "There are some really sneaky people who found a way to circumvent the rules and steal foreground activation." Well yeah, and there are some really sneaky people who find ways to steal love, so there you have it. If everything is right with the world, both groups of people will eventually be found out and made to suffer for their malfeasance.

Update (02/21): Deleted all comments that showed ways of circumventing the rules. Duh, people.

Comments (48)
  1. John says:

    Unfortunately for you, everything is not right with the world and you will be driven insane by all the backward compatibility hack shims you will have to write.  But at least Lotus 1-2-3 2.0 will still run on Windows 2048.

  2. Brian says:

    We, unfortunately, have a very legitimate reason to steal foreground activation.  We have an app that launches full screen.  What we noticed is that a lot of our users have a tendency to triple-click the icon on the desktop, thereby launching the app then giving focus back to the desktop.

  3. someone says:


    The behavior of explorer you mention does not  seem intuitive. On the other hand, it’s entirely possible that the user is triple clicking on purpose: Imagine, for some reason, the app takes a while to load, and in that time, the user decides to reorganize the desktop icons. In that case, if you bring your app to the foreground, you’re stealing the focus. Probably it is better to leave this decision (and possible enhancements) to explorer.

  4. Nick says:

    Uh, Raymond, I just checked and I couldn’t find any definitions for WHO_THE_HELL_ARE_YOU.  Admittedly that probably would be too cool to actually have in Windows. Maybe I need my own set of headers:

    if (AllowSetForegroundWindow(pid) != WHO_THE_HELL_ARE_YOU)



    Forget Lotus, my metric of failure is Visicalc. When that stops working then Windows will be dead to me. Dead!

  5. Brian says:

    The user sure would have a hard time rearranging icons with our app full screen in front of it.

  6. Rick O says:

    I have to wonder (abstractly) the repercussions of shimming that function to a no-op.  Because, truly, it drives me crazy to launch an app that I know is going to take a while to load up, and then have it keep stealing focus while I’ve gone on and continued to do other things.  Launch, click something else, the app steals focus but still isn’t done, click away again, app steals focus yet again, repeat.  Word, Photoshop, Outlook, iTunes, Nero, and many more do it.

    I’m trying to think of a good use-case where I would want to let an app steal my focus from another app.  Even at launch time.

    Maybe I just don’t have the same expectation that "normal" users do?  If the expectation is "when I launch an app the next thing I want to type into is that app", which leads to "let the app keep stealing focus until it is ready", then yeah, I definitely don’t share that.

  7. Brian says:

    I should qualify, when I say full screen, I don’t mean maximized.  I mean it literally covers your entire screen, including start menu (think video game or power point presentation).

    Specifically what was happening is the user launched the app by triple clicking, then started typing, but input wasn’t coming to our app.  Since we also hide the mouse, he couldn’t exactly click on our app to give it focus.  He subsequently filed a bug.  This happened enough times to enough people for the bug to be elevated from “Will not fix – User error / Microsoft problem” to “OK, we have to figure out a way to work around this”

    [You can still click with a hidden mouse. Once they click, the click will go to your application, and you’re back in business. -Raymond]
  8. Brian says:

    ok then, he didn’t know he could click, because his mouse was hidden.

    Either way, we had 3 options:

    1) Fix it

    2) Hope Microsoft fixes it

    3) Tell the users to piss off because they’re doing something dumb

    Now which of those 3 options would make our users the most happy?

  9. JamesNT says:


    Sadly, most third party guys choose option 2 as the best way to make users happy.


  10. Jeff Tyrrill says:


    "Specifically what was happening is the user launched the app by triple clicking, then started typing, but input wasn’t coming to our app.  Since we also hide the mouse, he couldn’t exactly click on our app to give it focus.  He subsequently filed a bug.  This happened enough times to enough people for the bug to be elevated from "Will not fix – User error / Microsoft problem" to "OK, we have to figure out a way to work around this""

    No, they didn’t launch the app by triple clicking. They launched the app by double clicking, and then clicked the icon again. That distinction is critical.

    "The user sure would have a hard time rearranging icons with our app full screen in front of it."

    Way to miss the point. Obviously, the third click did occur prior to your full screen app covering it.

    Why are just the users of your application triple-clicking? Why don’t you have your application not hide the mouse until it has focus?

    Sometimes, you just have to let user error resolve itself. Rather than calling for Microsoft to "fix" something that is not broken, and was a huge, much-appreciated change when it was implemented in Windows 98 (or was it 2000? forget which) to stop programs from stealing the focus.

  11. Joseph Koss says:

    Watchdog apps also needed to steal focus from time to time… just to say "IMMEDIATE ATTENTION REQUIRED! THE FREAKING THING-A-MA-JIG IS DIS-COM-BOB-U-LA-TED!"

    Basically, at one point it was OK for applications to steal focus, and then it later on wasn’t, where a new "notification area" was thought up.

    There isnt a middle-ground but I can see multiple cases where there should be.

    I’m certain that the IT department where I work would probably like such ability, because the front end software (of which there are several dozen department-specific programs) on the hundreds of floor terminals isnt theirs, so cannot be coaxed into giving up focus with legitimate methodology.

    There are cases where company-wide (a casino) broadcasts of a discrete nature would be advantageous for security reasons… its too easy to ignore/overlook the notification area.

  12. Funny that no-one has yet mentioned Internet Explorer’s tendency to randomly set itself as the foreground window. Well, OK, that’s not necessarily reality (something else is probably pulling it forward) but still, the number of times I’ve had an IE window pop to the front of the stack, even in IE7, cannot be counted.

    Here’s something worse though, with the "I wanna be seen NOW" concept. What if a user is typing a document, and you have a button as the default control in the window? Why, the very next space or enter (which could be as early as the next keypress) – or even the correct matching accelerator key – causes an action to be taken that the user cannot review.

    I do wish there was a system option to "convert the SetForegroundWindow function to a no-op". I know it cannot be, for thousands of reasons including undoubtedly breakage, but still it’s nice to dream …

  13. Ray Trent says:

    "We, unfortunately, have a very legitimate reason to steal foreground activation.  We have an app that launches full screen.  What we noticed is that a lot of our users have a tendency to triple-click the icon on the desktop, thereby launching the app then giving focus back to the desktop."

    That’s not a legitimate reason. Stop doing that, it’s really irritating. Your app doesn’t own my computer, I do. If I give focus to the desktop, it’s my choice to do so.

    Here’s a real *legitimate* reason to steal foreground focus: you’re a background service/app whose function is to be a user-activated application launcher.

    For example: monitoring a hotkey button that the user has configured to launch some application. Or pop up a timed alarm the user has requested, or, or, or…

    There’s no input message that the OS recognizes, and yet it’s truly the user’s intent to bring the launched app to the foreground.

    To use Raymond’s analogy of "stealing love", this case is similar to BDSM :-)… it’s all about consent and *clearly* communicated user intention.

  14. Nick Mason says:

    I agree with Ray Trent.  I’ve written a launcher app that has been rendered completely useless by this.  I wish there was a registry key (writable by admins only) that stated which apps could steal the focus, even if it were settable by me on my own machine for me own use.  I’ve given up on my app now thanks to this.  On the other hand, I hate apps that steal my focus without my consent.  Like the Windows Update *I ABSOLUTELY MUST REBOOT NOW AND I’LL INTERRUPT YOUR SESSION EVERY FIVE MINUTES UNTIL YOU AGREE WITH ME* prompt.  Some middle ground must be attainable.  I’m the admin of my machine, why as an admin, can’t I make it behave the way I want? With my own sofware?

  15. Worf says:

    The problem with stealing fforeground is the user may be merrily typing away not looking at the screen (since knowing how to type means you can type and review notes, etc without looking at the screen).

    Oh hey, user types a space and dismisses your dialog. In the meantime, user sees a flash, and realizes that they lost stuff. Many a popup has been lost this way, hence the balloons – they stay up until dismissed on purpose, rather than accidental. Do this with a window, and you’ll have a frustrated user who lost who knows how much because they thought they were composing something, but your app was eating it instead.

    As for Windows Update – if you set it so it doesn’t auto-reboot, move the window out of the way with the cursor keys and the Move command in the alt-space menu.

  16. someone says:


    Even if a fullscreen app is running, there are legitimate reasons for having a different process in the foreground. Just think about a process running on a different monitor or a configuration tool. Window manager hacks are likely to cause unexpected trouble in other places. What if two fullscreen apps try to become foreground windows, which one is supposed to win?

    I think the better solution is in any case inside the app, for example, by giving the user a clear visual indication that the fullscreen window does not (yet) have the focus.

    I admit Microsoft could do much better in fixing all those Explorer UI annoyances, particularly in older versions of Windows.

  17. Anonymous Coward says:

    Focus is a hard problem. On the one hand it can be a security vulnerability, for example if an untrusted or semi-trusted (like a browser) application that is otherwise sandboxed grabs it just as you’re typing a password or something. On the other hand there is the expectation that pressing Logo, N, B, L, A, will open notepad with the text "bla" entered. Similar with a calculator or a console.

    As for the current mish-mash of focus grabbing, it seems like Microsoft does this: allow it, because sometimes it may be useful. Everyone does it, even though it isn’t. Disable it, but allow another method, because sometimes it may be useful. Tell everyone not to use it. It gets used. Disable the new way in the next OS release. But other ways still exist. Worse, these are all so hackish (in the sense of not original intended to be used like that and possibly having major side effects) that they’re all accidents waiting to happen.

    The only real solution I can think of is either a thorough revision of the security and UI model, or simply not using focus grabbers at all. But what if all the software that does a certain task is evil? Path them? I prefer not to use such hacks, for obvious reasons. And if such patches were to become prevalent, expect the next application update to disable them.

  18. Michael says:

    Why not just let the user select applications that have the permission to always call SetForegroundWindow? I often miss Outlook calendar reminders because the reminder dialog pops up somewhere in the background and I don’t notice it immediately. I would definitely put that dialog on the "always foreground" list.

  19. MadQ says:

    I was wondering how long the circumvention comments would last ;-)

  20. Brian says:

    The core problem is that SetForegroundWindow is trying to read the users mind.  It’s got a fairly long list of cases where it think the user probably wants the process to take focus, and it assumes in all other cases the user doesn’t want the process to take focus.  This works fine assuming it were always right, but the fact is, it’s not.  There are cases where the user wants a process to take focus, but it falls outside of the allowed cases.  What then?  Application developers are forced to coerce SetForegroundWindow into allowing them to take focus using one of a dozen methods that all make Raymond wince.

    The only real way for SFW to know which process the user wants to allow to take focus is to implement some kind of white list like what Michael suggested.  Unfortunately, that creates yet another user preference with all the UI dialogs and testing involved.  Not to mention apps would likely just figure out how to add themselves to that list.

    But wait, the user already has a list of apps he wants to allow to take focus: the list can be viewed in the add/remove programs dialog!

    While it would be extremely annoying for my PDF viewer to constantly steal focus so it can tell me an update is available, if it did that I’d switch to a different PDF viewer (or file  a bug report).  The same as if the viewer crashed all the time or if it took up half my memory/cpu or if it transmitted confidential data to their website.

    [Okay, let me see if I am reading you correctly. You’re saying that any program the user has installed has been implicitly granted permission to take foreground? (Because if they didn’t like it, they’d uninstall it.) In which case, you’re arguing for removing all attempts to block SetForegroundWindow? -Raymond]
  21. Nick says:

    @Nick Mason, Worf

    For Windows Update on XP, the best solution I’ve found is to use a program that allows you to minimize windows to the system tray/notification area.  This prevents further disruptions or accidental restarts. A good free one I use is PowerMenu which adds several window controls to the system menu of each window.

    The 4 hour delay was one change I was glad to see in Vista, though that box has it’s own problems.  The dropdown selection is directly over the Restart Now button which can lead to many accidental restarts.

  22. someone says:

    I’m currently modifying an application where focus stealing would be really useful.

    If you call a second instance, it shouldn’t run, but bring the first instance to the foreground and notifying it about the new command line. (classical situation)

    It should be able to run it on 95, so AllowSetForeground isn’t really an alternative.

    The second instance can’t call SetForeground, because it doesn’t know the handle of the first instance. And it can’t use FindWindow or something because the window title changes during the time and the class name is is just the name of window library’s window class.

    And although the first instance can determine its own handle, it can’t send it to the second instance because the used communication library seems to work only in one direction. As soon as an instance is registered as main instance, every other instance can send message to it, but it can’t send some itself. (I know that’s crap, but I didn’t wrote that library)

    And since this application is platform-independent, calls of Windows functions should be minimized, so rewriting the communication library with normal Windows functions is also not a nice solution. (Actually there is not one direct call to any Windows function)

    [If the second instance can send a message to it, it can pass its own window handle as part of that message, and then the first instance can send a reply with the window handle of the first instance. -Raymond]
  23. John says:

    You can stop the Automatic Updates service in order to get rid of that annoying, focus-stealing dialog.

  24. Leo Davidson says:

    [… You’re saying that any program the user has installed has been implicitly granted permission to take foreground? (Because if they didn’t like it, they’d uninstall it.) … -Raymond]

    Sadly, that seems to be the opinion of at least two members of the Engineering Windows 7 blog, from recent posts.

    Except the thing they’re saying we give implicit trust for all running code to do is silent local process elevation, not just taking the input focus.

    (I’m not saying it’s your fault; just thought the parallel was worth pointing out.)

    OTOH, I suppose it’s easier for an app to accidentally take the focus than it is for one to accidentally bypass the elevation prompts.

  25. dave says:

    The problem is hard because practically every application developer thinks that his application is bold blink underlined **IMPORTANT** /bold /blink /underlined, whereas to us users, it’s just one of many things running, and we’ll get round to looking at it later. Maybe.

    App developer thinks he’s in charge of your UI; user thinks he’s in charge of his UI.

    User is right, always.

  26. Brian says:

    [Okay, let me see if I am reading you correctly. You’re saying that any program the user has installed has been implicitly granted permission to take foreground? (Because if they didn’t like it, they’d uninstall it.) In which case, you’re arguing for removing all attempts to block SetForegroundWindow? -Raymond]

    Pretty much, yes.  The blocks on SetForegroundWindow don’t do any good (because programmers have figured out workarounds) and in fact do harm (because those workarounds can have nasty side-effects).

    One could argue that the blocks cause a programmer to think twice about if he really wants to take the foreground, but what happens in reality is he notices the function isn’t working, googles it, finds a workaround, pastes it in, and goes along his merry way.

  27. says:

    Thanks for this article. I use two modified versions of Taskmgr as system monitors. They always have trouble shutting themselves down after I start the Shutdown process. Now I know why. I stole love and have suffered from unreciprocated feelings. At least I know why now.

  28. One of the things I really dislike about IE is this use-case:

    1- I click on a link

    2- IE starts to munch because the link needs a zillion files to load

    3- I switch to another application (like: do some real work and start typing)

    4- after a while IE suddenly comes in the foreground and steals the key-strokes (for instance the space-bar or enter keys, especially horrible when IE pops up a modal-dialog with a default button)

    This gets worse when you start a bunch of URL’s that you know you will need in a few minutes.

    My current workaround is that I have banned IE to a VM or an RDP session. Which has the drawback that a couple of times a day some app breaks the clipboard chain and copy-paste to the VM or RDP session fails.

    I’d opt for a blacklist of applications that are not allowed to steal the foreground.


  29. Ross Bemrose says:


    Do you work at Valve software, by any chance?

    Team Fortress 2 takes so long to start the first time I run it after boot that I often start setting away messages in my IM programs while waiting for it to start.  If I finish before it does, I click on the loading message to bring it back to the front.  If it finishes before I do, the application appears as a borderless box in the lower-right of my screen.

    Luckily for me, it fixes itself when it moves to the menu screen, but that brief spot when the Valve and Source logos are on the screen is somewhat annoying.

  30. someone says:

    [If the second instance can send a message to it, it can pass its own window handle as part of that message, and then the first instance can send a reply with the window handle of the first instance. -Raymond]

    Principally this could work, however this communication happens before any windows are created. And I don’t know how the GUI library handles messages it doesn’t know.

    [If you have nobody to send the reverse message to, the return value of the message could be the window handle (if your messages have return values). Good luck with the unknown messages. Sounds like the authors of the GUI library never considered the cross-process focus management problem. -Raymond]
  31. configurator says:

    @Jeroen Pluimers, I use a much simpler workaround… Google Chrome. It doesn’t steal focus AND it doesn’t take hours to load because of eager rendering (or something, I’m not sure why it’s so fast). That doesn’t work for the Windows Update reboot prompt, unfortunately!

  32. Mark says:

    Brian: the simplest (and IMHO best) solution would be to not have your window full screen when it’s not the foreground window.  This is the approach almost all games take, and not only stays out of the user’s way, but also gives a hint to your 3-clicks person that they’ve changed the focus themselves.

    Intuitively, focus on a windowing system should be controlled by the user.  Any time you break that, you’re changing their expectations, and preventing them from associating "I clicked on something else" with "the window I want isn’t in at the front".  Too many Windows programmers have done this in the past.

  33. someone (first one) says:

    Deleted all comments that showed ways of circumventing the rules. Duh, people.

    That is unfortunate because people were illustrating a point.

  34. ulric says:

    Interesting discussion with the the case brought by "Brian"

    How would I handle it…  Assuming this occurs because the app is slow to load  and people end up clicking multiple times, I think I would provide immediate feedback the application is loading up by poping a progress bar (or slash screen) very quickly.  If the main executable is slow to load because of dependencies, I’d create a small excutable that’s just the loader for the rest.

    I’d also provide visual cues that the app is not focused one, possibly by graying out the main window graphics.  

    I very much doubt that people actually tripple-click. The probably instead click multiple times because a wait cursor or loading screen is missing and they think their action did nothing.

  35. Christian says:

    I recently switched to Vista and in XP I sometimes launched TweakUI (which was written by …) and there I could disable SetForegroundWindow. I often found it in the wrong state: So that programms could steal focus.

    I just found some tip on the web that shows how to force a window on top and it works by modifying some global setting. How scary! These stupid stealing programms change this setting!!!

    Well that explains why my setting sometimes are changed. I don’t know which programm did this.

    The bad thing now is: There is no TweakUI for Vista. Does vista still allow any programm to disable the taskbar flashing in favour of focus stealing? How could I change it back? How could I lock it???

    Oh and I just created a batch file that just stops windwos update (net stop wuauserv). Now I can just click that on the desktop whenever the annoying stupid windows update dialogue appears every 4 hours. Yeah!

  36. ulric says:

    I’m thinking the people complaining about focus stealing like it’s ruining their day must be running windows XP or earlier. Even in XP, I can’t recall IE ever stealing the focus. I do recall IE stealing the focus in the past(for example the download complete dialog)… but that was years ago, I think it was Windows 2000.

  37. Brian says:

    "I very much doubt that people actually tripple-click."

    I didn’t know about triple clickers either until this particular bug report showed up.  I didn’t even figure out what was happening until I went out to the customers site to investigate and witnessed it first hand (we write very niche software with only a couple hundred users where each user pays multiple tens of thousands for the software, so going out to a customers site is not unheard of).  In this case, the user was well over 50 years old, so it was easier for me to quickly modify our software to add SetForegroundWindow (with a workaround to allow us to steal the love) than retrain him in how to use a mouse.

    Interestingly, triple clicking is mostly benign in just about every other case, which is probably why he never had a problem with it before.  Also, after this happened I noticed my mother occasionally triple clicks as well (though, she doesn’t use our software).

  38. Igor Levicki says:

    I have an idea which will make me rich.

    I will make a mouse which filters clicks dropping every third which occurs in a rapid succession.

    Wait… why make hardware when it can be done in software? Just install the mouse filter hook!

  39. Miral says:

    I would be much happier if there were a user-controlled *blacklist* of applications, so that I can ban SetForegroundWindow from ever taking effect for that app.  I’d even be reasonably happy if the standard behaviour was to grant permission to all apps not in the blacklist.  That way, I could specifically block those apps that abuse the privilege, whether intentionally or unintentionally.

    I suspect that most of the times that focus-stealing has happened to me, it’s been unintentional on the part of the app.  (I’m fairly certain in one case that MessageBox itself is the culprit — whether that’s due to passing NULL as the parent or to passing some special flag (eg. MB_SYSTEMMODAL), I’m less sure.)

  40. Rob says:


    "Brian: the simplest (and IMHO best) solution would be to not have your window full screen when it’s not the foreground window."

    No! Please never do this, it’s very annoying to people with multiple monitors. How about just unhiding the cursor?

  41. Luke Breuer says:

    It seems like Microsoft would benefit everyone by creating a sort of "programs doing stuff notification area".  Programs that are starting up or [temporarily] frozen would go in that area.  The user could control what happens when the program actually starts up or not.  In effect, you give the user control over whether or not a program can steal the focus.  Maybe you default this to not show up or allow programs to steal focus, so that current behavior is maintained.

    Document this functionality extremely well, and allow people to submit situations which aren’t covered by the API.  After finalizing the API, start documenting a list of companies that just cannot seem to follow the rules.  Maybe public shame would work?

    My core question is this: to what extent is Microsoft serving its end-users, versus its big corporate clients who want to impose their stupid rules on everyone?  I hope Microsoft realizes that it will have to make all sorts of Windows experiences better and better over time, or something open source will eventually catch up.  It would be nice if MS could avoid going the lazy route it went (and is still pursuing) with Internet Explorer.

  42. Mark says:


    Okay, you deleted all the code samples that show how to circumvent “SetForegroundwindow.”  How about providing a code sample which shows the correct way to do it?  

    This is a classic case of code which should be written once and copied forever.  Rather than have every developer do the research, hunts down the bugs, etc, etc, I assume you already have a piece of working code since you clearly already know the right answer.  Can you post it and thus obviate the need or desire for people to “cheat?”  

    I have no hacker’s pride, and don’t need to re-invent the wheel.  If the user tries to start a 2nd instance of my app, I just want a simple, debugged piece of code for letting my 2nd instance tell the 1st instance to set itself as the foreground window.

    [I already described the way to do it in the article. Call SetForegroundWindow from the application that was launched, not from the first instance. If you really want to see code, here it is:


    There ya go. Copy it all you like. -Raymond]

  43. Timothy Fries says:

    @Luke Breuer: Talk about an overengineered solution to a minor problem.   You have far too much confidence in both users and developers.

  44. Aaron G says:

    @Luke Breuer:  Great idea!  Makes me wonder why Windows doesn’t already have a Notification Area!

    …What’s that you say, Windows already has a Notification Area?  Since 1995?  Oh, well, never mind then.

  45. DWalker says:

    @Brian:  Why can’t you just tell your users to stop triple-clicking?  I’m serious.  They should learn not to DO that.

  46. DEngh says:

    @dave "The problem is hard because practically every application developer thinks that his application is bold blink underlined **IMPORTANT** /bold /blink /underlined"

    In my team’s case it’s not the developers, it’s our marketing people.  We keep having to tell them that we don’t get to take focus every time <the current event of concern> happens in our app.

  47. Mark says:


    I was politely asking for a useful bit of code, and you treated me like I was some sort of tool.  

    I read your original post, and I already understood the way to call “SetForegroundWindow()” with the handle of the first instance.  I’m not retarded.  Unfortunately, you glossed over the key details via the equivalent of, “The rest is left as an exercise for the reader.”  While it’s all fun to be smarmy and say “hwndFirstInstance”, how about providing useful code that provides a way for the 2nd instance to get the handle of the 1st instance?  “FindWindow()” is a fairly flawed system, such as detailed here:

    So, care to step up to the plate, or do I get another “There ya go” from you?  Seriously, when someone acts like a dick, treat them like a dick.  When they ask like a decent person, treat them like a decent person.  

    [Um, you presumably already know the handle to the first instance since you were going to send it a message to say “Here, take over for me.” Today’s topic was how to manage foreground activation during the hand-off, not “A complete guide to single-instance applications.” I had assumed your question was “What change do I have to make to my hand-off code to manage foreground activation correctly?”, and I answered it in that context. I didn’t realize you wanted “A complete guide to single-instance applications.” My apologies for misunderstanding. But you won’t get an answer today because that’s not today’s topic. Don’t make me bring back the nitpicker’s corner. “Today’s topic is the management of foreground application during the hand-off from the second instance and the first. It assumes that you have already figured out a way to get the two instances in touch with each other.” -Raymond]
  48. Luke Breuer says:

    @Timothy Fries

    You call it a "minor problem" because… it doesn’t bother you much?  Have you seen what non-guru users do to deal with these problems?  Tell me this: what happens when we allow a system to have many minor problems?

    @Aaron G

    The fact that Microsoft itself circumvents the "tooltip should fade away after a while" design criterion should tell you something.  Here’s a hint: Windows’ notification area sucks and probably due to no interesting changes since 1995!  Look at Growl on the Mac and see how many more options it has, like, say, stacking notifications.

    As far as I can tell, there are at least two major problems why companies circumvent what Microsoft says to do:

    1) it is too hard to find the proper documentation (not everyone is a Win32 guru), or the documentation is incomplete

    2) companies want to do something that Microsoft says not to do so instead of using a standard API, they come up with a hack that requires shims for backwards compatibility down the road

    I’m not going to expect more from users, but damnit, I will expect more from Microsoft.  Hell, they can turn out nice products like SQL Server and the .NET Framework — how about applying that level of expertise and diligence to other areas?

Comments are closed.

Skip to main content