| Date: | October 14, 2003 / year-entry #95 |
| Tags: | history |
| 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)
Comments are closed. |
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?)
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!
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.
I’m down with it. Pramod, can you name one potential advantage that has been denied a well meaning developer?
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.
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 ;¬ )
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.
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.)
Commenting closes after two weeks.
http://weblogs.asp.net/oldnewthing/archive/2004/02/21/77681.aspx