I like your restaurant analogy... I was in New Orleans a couple of weeks ago, and took time to visit my favorite restaurant there: Mother's. Amazing food, great prices, constantly busy, but... Not the sort of place where someone sits you down, takes your order and chats about the weather. You're expected to know what you want, ask for it, pay, and get out of the way until your food is ready to be picked up - if you screw that up, you'll be gently but firmly informed of protocol. SO aims to be the Mother's Restaurant of programming Q&A sites - open to all, providing good results fast. Anything that gets in the way of that is ruthlessly stripped away. BTW, if you ever encounter issues with your account again, just let us know[^] - I or someone else will fix it.

You must be careful in the forest Broken glass and rusty nails If you're to bring back something for us I have bullets for sale...

Bingo. FWIW, I collected some stats a while back on how much cruft gets deleted for various reasons. One of the things that persistently irritates me about searching for problems on the 'Net is wasting time clicking through to unresolved problems - getting questions that can't be effectively answered out of circulation to make room for those that are is critical, IMHO.

You must be careful in the forest Broken glass and rusty nails If you're to bring back something for us I have bullets for sale...

Check the options in the software you're using to burn the mix - many have some sort of volume normalization feature built in (even if it's hidden away in an Options page somewhere). Alternately if you're burning MP3s, use MP3Gain[^] to analyze and normalize the set before burning them. Oh, and congratulations!

Meh. New UI features in Vista and Windows 7 were mostly available first via unmanaged APIs, with some managed wrappers. Early hints of deep integration for WPF apps were mostly unrealized. If you're feeling that your time has been wasted, you should've started feeling that way long before some early next-gen demo.

Chris Maunder wrote:

which I'm sure was created by the same agency that gave us .NET, didn't give us a hint why it was all caps, and then provided a logo with ".net".

.NET did pretty well aping Java while appealing to Windows devs > half a decade too late... If that's their strategy here, good for them. "You have to re-write your app, but we'll make it easy for you" is a much better message than the "you don't have to re-write your app... but it'll work like crap" thing they've been trying to push for tablets the past decade.

idspispopd ftw!

My latest productivity booster? Sitting on a local river bank, near a waterfall, with a laptop. Still doesn't beat multiple monitors for debugging UIs though. Gotta get me one of those chess clocks...

Chris Maunder wrote:

we were thinking that there are probably developers who have never heard of a BFG 9000, let alone what it stands for (official and non-official)

Ok, thanks. Nothing in this made me feel old, but imagining developers coming of age post-BFG does. I'll just go shop for a cane now. :rolleyes:

I really can't imagine this working out well for MS. For that much scratch, they could afford to beef up their own VOIP offerings... and give away free calls... to drum up subscribers; this is the sort of money you'd expect them to lay out for a robust platform, but I have a hard time believing they won't face the same issue described in that article: in order to integrate, they'll end up putting their own engineers to work re-writing the whole steaming mess. If this *was* Google, I'd suspect they had some subtle plan up their sleeves. Might take half a decade to come to fruition, but... But it's MS. They do best integrating things that are already pretty close to their own offerings. This isn't. It's doomed.

Rutvik Dave wrote:

But the text looks fine to me. (This might be graphics card driver issue, as now everything is using "Hardware Accelaration" )

It might also be a driver issue since if your video driver isn't supported (or is blacklisted[^]), you won't get hardware-accelerated drawing. So I don't see any change at all on my laptop (out-of-date Intel driver), but on my desktop I get smoother (not really blurry, but obviously different) rendering.

This doesn't particularly surprise me... When Bing first came out, the most noticeable difference between Bing results and Google results could be seen when searching for more obscure topics: both engines had staggeringly large indexes to draw from, but Google's was far more broad. That's probably not an easy problem to solve: you might be searching for a term that is only relevant to a tiny handful of pages, pages that might not even actually contain the exact term itself (due to alternate spellings and such), and only have a single inbound link... Sure, in another few years, with constant effort Bing might broaden its index to meet or surpass Google's; but in the meantime, they'd be getting saddled with this reputation as the "mainstream searches only" engine. Snagging search results is a bit underhanded, but probably a lot faster. And if (as the article suggests) they de-prioritize the results when other information is available, it shouldn't really hurt Bing's competitiveness (in terms of becoming just a rebranded Google...)

Good to know, thanks for posting this! And, about time... LL hooks can stall input processing. If your hook gets removed because it times out 10 times, that's 3 seconds of lag it introduced into the Windows UI. Not your program's UI, the entire desktop. That's unacceptable! You shouldn't be doing any serious processing in a hook routine; check a flag, post a message, and return - if this consistently chews up more than 300ms per call, something is very, very wrong. And you won't even get the blame for it. User notices all their apps are laggy, they blame Windows, not some program that doesn't even have input focus. Maybe eventually they figure it out, after re-installing Windows and finding that helps right up 'til they get around to running your software again... But probably not. I suspect they realized this was causing problems and rather than simply reducing the default timeout value (which might have caused problems for software that has a legitimate need to eat certain input events), they decided to just go after software that consistently hurt performance.

Or they just don't want to handle support requests from folks trying to copy "protected" DVDs...

You must be careful in the forest Broken glass and rusty nails If you're to bring back something for us I have bullets for sale...

White. Pure white. It reflects all the colors, so you can see whatever you want just by wearing tinted shades. Make sure you get the floor, desk, PC, and assorted cabling as well.

You must be careful in the forest Broken glass and rusty nails If you're to bring back something for us I have bullets for sale...

Ed Gein was a very good fellow you know...

You must be careful in the forest Broken glass and rusty nails If you're to bring back something for us I have bullets for sale...

Mike Hankey wrote:

goofy crap like the "Juicer"

It's probably over-priced, but... I borrowed one last year to make a small batch of cider, and the thing actually worked pretty well.

You must be careful in the forest Broken glass and rusty nails If you're to bring back something for us I have bullets for sale...

I didn't know you could get pure caffeine that easily... Cool...

You get run over by submarines.

Well, let's be fair: some of us have to work with databases where the schema has been around for years and where we can't change the design on a whim... even if the design is less-than-adequate. For my own use, I would avoid both nullable int fields and .NET DataSets... But if you're stuck with both, then you gotta make do. Hence the question which you didn't really answer.

Marc Clifton wrote:

Come on, MSFT, you could have cached the references as a background thread while I'm still futzing with creating projects, edit code, etc!

That would be annoying. I use the "add references" dialog maybe once every few weeks; why should VS decide to background-scan the registry (while also background-recompiling the Intellisense database with occasional breaks to background-load debug symbols) every day? The rest of the UI issues (bouncing list, sketchy scrolling) could have and should have been handled more effectively. But then again, it took them a decade to get around to the background loading thing - this little dialog just doesn't seem to have much priority...