In certain cases, doing this would allow the process to handle returning data faster, especially if it was having to communicate with Excel a great deal and there was a lot of context-switching/waiting between the processes and you wanted to favor Excel's processing of the returned data over a background task with high CPU usage.
Perhaps the problem is that pieces of the Excel side were timing-out and causing all the returned data to be lost.
To read more about UI thread boosting in Windows, this article is a pretty good one:
The LockWindowUpdate function disables or enables drawing in the specified window. Only one window can be locked at a time.
I've never really considered why that may be the case. This makes a lot of sense.
So while it's funny to say, "haha, isn't this typical of stupid M$," they apparently didn't produce this advice. More likely, some support tech recorded the mouse bit from the customer just to be complete, and 7 years later it still hasn't been verified...
First thought: this has got to be a parody.
Second thought: Oh Cthulhu, it is for real.
Third thought: Just by mentioning this link almost anywhere, it'll be excoriated as "just another baseless attack on Microsoft (which I, being a technologically fair and balanced soul, will admit to having less than stellar practices)"
Does anyone know if these http://ishmeet.wordpress.com/2007/09/28/3-wicked-microsoft-b... still exist?
The =rand(200, 99) one looks interesting.
It's primary use is for layouts when you need some filler text.
The second? No clue.