Attempted suicide is still a crime in many places, as it was in the UK until 1961. Committing suicide was a crime too, punishable by various means at various times, from forfeit of your estate so your family do not get anything to your body being refused proper burial or being mutilated. Most suicide laws are / were based on crimes against one god or another. Every man can tell how many goats or sheep he possesses, but not how many friends. Shed Petition[^]

Here[^] - when it was just the Rutherford Labs, and had an Atlas Computer Division, physically right next door to the Harwell Nuclear Research base. That was always fun! They shared medical facilities which were based in the armed-guard-and-no-f'ing-about part (since Harwell understandably had seriously good facilities) which lead to a friend being taken to get a couple of paracetamol for her headache with an armed motorcycle escort. All she did has admit her name was Krys Zarczynski, and she was from Poland... :laugh: Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water

That's interesting. As I experiment with different UI actions, I am starting to get the impression that it is not just any app modal dialog that causes the issue; rather, I think the dialog has to be an Office app modal dialog. In fact, the problem may not be the dialog per se, but may tie back to OLE, embedded documents, and such. The infrastructure that those features rely on is pretty antiquated and was developed during a time when all sorts of app-level scenarios were capable to locking up the whole Windows GUI (i.e. the time of "cooperative multitasking".) Relatedly, this may not be a Windows 7 issue so much as it is an issue that arises when doing advanced, cross-product things in Office.

_beauw_ wrote: Second, I am unable to expand the comments posted below the articles. Perversely, this bug affects Chrome but does not seem to happen in IE7. I get this problem with Chrome too. Ooooh, Shiny!

I know the tip is a sloppy one. It was probably a bad choice of example on my part. The exact bug you point out is a severe one, and can happen on a wide variety of platforms, even single-process ones. I do not think that really affects my argument though. The issue for me is not the quality of one particular tip, it is the nature of the criticism leveled at it. No one posted a response to the tip explaining its bug(s), or why it does not work well in a multiprocessing environment. The response was (paraphrasing) "this is garbage because it doesn't have command line arguments." And I am sure an equal number of people looked at the tip and asked "where's the GUI?" In my original post I wanted to use someone else's tip, to make my point more objective. But perhaps one of my own tips[^] is a better example. In the tip, I provided a signature-compatible GDI+ replacement for GDI's StretchBlt() function, which adds anti-aliasing. There are a variety of potential issues with what I posted: it is not particularly fast, a full rewrite might be better than simply dropping in a replacement function, etc. I expected criticism on these points. However, the nature of the actual criticism I got was a bit unexpected. Someone posted a response with the subject line "Just use Bitblt of GDI in WM_PAINT, resize at other." In other words, the suggestion is to draw the image at its native resolution in WM_PAINT and then resize it using other (unspecified) means. You can read my response to this post at the tip itself, but in short I do not see where WM_PAINT necessarily enters the discussion... this is a classic example of the anti-pattern I pointed out. Of course, relying on some other unspecified magic to do the actual work of resizing the image (the whole point of StretchBlt()) is not valid, either. To summarize: when I post code, I am not necessarily suggesting an architecture. In criticizing my code, be brutal; point out bugs, potential optimizations, etc. But please do not place my code into some assumed architectural context without a valid reason.