Why don’t notification icons get a message when the user clicks the “X” button?

Date:October 14, 2003 / year-entry #95
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20031014-00/?p=42173
Comments:    9
Summary:If such a notification were generated, ill-behaved programs would just react to a click on the balloon's "X" button with an annoying follow-up dialog like, "Are you sure you want to ignore my wonderful message?" So there was a conscious decision not to give them the chance. In the Before Time, software was trusted not...

If such a notification were generated, ill-behaved programs would just react to a click on the balloon's "X" button with an annoying follow-up dialog like, "Are you sure you want to ignore my wonderful message?" So there was a conscious decision not to give them the chance.

In the Before Time, software was trusted not to be actively evil, not to second-guess a user's action, not to invade a user's private space.

Over the years, we've learned that this was a naïve position to take. So now, when we decide that something is an end-user setting, we actively avoid giving programmatic access to it, so programs won't be tempted to weasel themselves into it.

Comments (9)
  1. Mat says:

    Not having played with the irritating balloons much I may be talking rot, but would it not be possible for an application to check whether its balloon is still there every couple of seconds (via a window handle or some other mechanism), and if it’s gone before it would have naturally expired pop up another one? I’ve noticed on a few occasions that some balloons are a bit persistent, WIndows Update in particular — dammit, I KNOW updates are ready to download! (Shurely not another undocumented API call?)

  2. Pramod says:

    I don’t think that disallowing programmatic access to any event is a good idea. The fact that it can be misused by annoying applications is not justfication enough. Think of the many potential advantages that you are denying to well meaning developers!

  3. Blake says:

    Let me toss in a vote in favor of this policy. It is unfortunate that it needs to be this way, but I think it is a correct assessment of the state of software.

    There is a whole new security-type design point here, treating all applications as semi-trusted and only allowing them to over-ride the machine owner’s settings with explicit permission.

  4. Israel says:

    I’m down with it. Pramod, can you name one potential advantage that has been denied a well meaning developer?

  5. Steve says:

    Better yet, can you show me a well meaning developer who is knowledgeable enough to use this power properly, wise enough to know when it is appropriate and also humble enough to realize most people don’t want to see his bubble? No? I didn’t think so… 

    I personally am quite happy that Raymond and his peers have seen fit to keep people’s fingers out of my bubbles.

  6. AlisdairM says:

    A good example is some real-time monitoring software we use. As soon as an alarm fires, we want to take over the screen and alert our user "Serious error, needs attention NOW!"

    Over the years successive Windows OSes have made this harder and harder to do. As fast as we work out how to do this, MS are keen to shut it down as in the hands of antisocial software this can be incredibly unpleasant, not to say downright dangerous. Think what havok silent service spoofing your desktop could wreak.

    It is a nasty compomise to have to make, and for once I’m glad not to be the one dealing with it ;¬ )

  7. Mike Dimmick says:

    I develop vertical-market custom applications for Pocket PCs.

    Among the things we could do with having an API for: turning off ‘receive all incoming beams’ (the Symbol PDT 8100 and PPT 2800 monochrome devices share a physical serial port between the infrared device and the barcode scanner, which can’t be used if that option is enabled), setting the device’s locale to United Kingdom rather than the default United States, having a decent API for creating Connection Manager connections (while you can use RAS, and the shared source indicates how to configure serial devices that use the Unimodem TAPI driver, it’s quite fragile).

    I note that Internet Explorer still doesn’t behave properly with regard to SetForegroundWindow, if two IE windows belong to the same IEXPLORER process. This can happen if you start loading a page in one window, switch to the other window, then the first window completes loading and brings itself to the foreground – even if I was typing into the second window.

    There are other times when Windows gets stuck – I have to click between flashing taskbar buttons several times to get *any* of them to come to the foreground.

  8. Raymond Chen says:

    The IE problem is tricky. Programs are allowed to steal focus from themselves. This is important for things like "open a new window" to work. Unfortunately, this also means that IE can end up accidentally hosing itself. I agree that this needs to be improved. But you have to watch out for the case where one IE window is manipulating another IE window via script – presumably that needs to still work.

    I went and took a look at Windows Update. They display the balloon when you log on, and whenever something changes inside the update engine (a new update becomes available, etc). So it’s not that they’re doing anything undocumented. They’re just persistent.

    Alisdair: Your program can set the foreground lock timeout to zero. This disables most of the focus-stealing lockout rules. This is of course a power not to be taken lightly, and needs to be done with the user’s permission. (Which I’m pretty sure will be granted in your case since that’s sort of the whole point of the program.)

Comments are closed.

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index