We have a set (~50) of local mode reports hosted in forms as plugins (dlls) in our app. They were initially developed in VS2005 and later ported to VS2008. We are now attempting to get them working in VS2010. The reports use lists to iterate over a table, invoking a subreport with the ID (primary key) as a variable/parameter so that the subreport could select details from related tables and display them. Some of the subreports used lists and sub-subreports, on and on. However, as of VS2010, even once we get the reports building and running they don't work properly. When we attempt to assign parameters to a subreport in the parent reports' design[er] using Right-click -> Subreport Properties -> Parameters -> Fields Then either... Add to create a new one or f[unction] to edit one that's broken... We get "Report item not linked to a dataset." This happens even if the Field (name) appears in the "Value" combobox and we select it. Does anyone know how to fix this or get past it...

Goofey program but they get to blow the crap out of each others remote controlled vehicles with remote controlled 30 cal machine guns on their own vehicles, lots of high explosives, etc etc. I'd like to have something like that and be turned loose in our parking lot. There's a few peoples cars I'd enjoy taking out...

findstr is a command line utility available at the CMD prompt, not an API. Just type "help findstr" in the CMD shell and away you go. However since the whole thread is supposed to be in jest it's probably not important...

Not that I'm a fan of Vista (I'm not), but findstr still seems to work fine even on Vista (though I'm surprised it doesn't first pop a few security dialogs, then want to hit MS's site to verify licensing, then pop more dialogs asking you to upgrade, and then finally crash or hang... like so many other Vista features...)

I've been developing on Vista with VS05 since Vista shipped and for me VS05 was anything but stable on Vista. It used to crash so often that it went beyond frustrating to infuriating to so commonplace I hardly noticed. Sometimes not just several times in a day but several times per hour. It happened so often I wrote a command script to clean out the process space in the event there were orphaned processes etc, and put a shortcut on the desktop. Having VS05 crash, then clicking that link and restarting got to be so common I hardly noticed, it was just part of the dev process, like syncing/merging. We switched to VS08 several weeks back, and I've not had anywhere near the problems. To be honest I can't recall if it has crashed, because having VS/VSS (or one of the tools) crash on Vista has been so commonplace that, like I said, I hardly notice. Personally I long for the days of XP and stable VS05, when I could lock my machine at night in the middle of a debug session, come in the morning and unlock the machine and as soon as it repainted hit F10 and be in the next line of code, just where I left off (unless some type of timing etc was involved of course.) I can't even leave my Vista machine booted, much less logged-in/locked/in the middle of a debug session. Half the time Vista stops recognizing the KVM sometime over the course of the night and becomes completely unresponsive, at which point I have to power-down right in the middle of everything. That's much more painful than having to shut down everything and power down/up. I've tried contacting MS and/or submitting bugs, but all they do is immediately start questioning everything I do and so on, round and round, basically blowing me off and treating me like I'm the bug instead of their products.

In my experience in pro sound and on stages, gaffers tape is not less sticky and gooey and in fact quite the opposite sticks better than duct tape. It is however designed to be easy to tear, to stick famously to just about anything and everything and yet - like the blue masking tape - not leave a lot of (hardly any) residue behind when removed.

I agree. And it's not just programming, it's basic skills. During my last few contracts at M$, I would have been rich if I had a nickel for every time I had to help some "highly qualified" person with setting up their computer, putting it on the corpnet, teaching them how source control works, helping them with batch scripts and Perl scripts and balky build systems, helping them with bug and work item tracking SW, helping them with facilities and office reqs (even though the interal sites are right there for them to use), helping them with Office apps and their email clients, etc ad nauseum. Or high-brow SW engineers who don't know how to setup delegates/events/callbacks/etc (take your pick of languages and less common features), etc. They know all the tricks that get hit in the interview loops and they are solid SW engineers in the more abstract academic sense, but get lost in the production environment and when asked to do all those mundane and arcane things that their high-brow schools and profs see as being below their dignity. And while I wasn't involved in nor did I directly observe this at M$, at several other firms I watched mid-to-large scale development projects with lots of potential get run into the ground because overseas outsourced engineering kept delivering exactly what their legal staff told them they had to deliver: Mostly solid (in terms of functionality) but often hackish or unmaintainable etc code that was written to a months or years old spec (because that's what they were given) rather than what they were asked for. And overseas qa outsourcing that delivered huge volumes of bugs that amounted to spelling/typo/grammatical errors in text, trivial misalignment of controls on forms, all manner of nits and easy pickings and so on, while the truly nasty shipstoppers were left to be discovered by the ever-dwindling stateside dev and qa staff - who were being brow-beat the whole time because they weren't "...finding and fixing all the bugs..." like the overseas staff were. For better or worse outsourcing and globalization are here, but unless and until the overseas outsourcing houses and the people who work there start to see themselves as team players and start to "get it" about being part of the overall solution and not just people who write code (or do testing) to specs and so on, it's going to be a potentially negative thing.

I've worked at MS off and on and also participated in unofficial (dogfood) and offical alpha/beta processes. The problem is that 1) MS puts up a strong wall, even to internal voices and alpha/beta testers/adopters 2) Of the relative trickle which does get through, even that is heavily filtered before even being seriously looked at 3) Most perf issues are almost always punted to stabilization *after* alpha/beta in the belief that they'll have time to do perf work in that period. To their credit they often DO spend lots of resources on perf in that period, but unfortunately by then features and bulk code changes are locked out and that means that any perf issue that can't be fixed without a lot of code churn or risk will almost always get shipped 4) Most MS Product/Program execs, managers, devs, and higher level test types almost always have the latest and greatest high powered HW and therefore often don't perceive perf issues the same way the market does once the product ships. I watched and listened as untold hundreds of Vista devs (out of only those I was exposed to) scrambled, begged, pleaded, cajoled, and even spent their own money on high-powered machines and especially video cards during Vista, all the while saying that perf wasn't an issue because customers could just go buy the same HW. Yeah, right, like everyone who wants to or has to adopt Vista needs (or will be allowed to) acquire a dual or quad proc machine with a $500+ video card and huge, fast, expensive HDDs.

But I think that's the authors' point... Why should we have to 1) Hope to somehow discover that such a hack exists? 2) Have to go find the hack? 3) Implement the hack on each and every machine we work on?? As I see it, the fact that the hack even exists is MS's admission that they've failed and that their stuff is bloated crap.... Otherwise, why would they even put in a hack like that? And, having put it in, why don't they advertise it... Vista is pathetic in this regard (and far too many other ways...) It has that bloated, resource pig "SearchIndexer" that you can neither turn off nor kill, there's no controls or settings or UI, and working in concert with Windows Explorer etc it's supposed to make navigation easier... Yeah, right, as if... Instead what happens is that even though the SearchIndexer is running continuously in the background, if you happen to "touch" or click the wrong folder in WE (and who can tell, now that the thing is so visually cluttered and busy and poorly laid out), WE **STILL* freezes minutes or even tens of minutes!!!! Doing what??? It's gotten to that point that anymore, anytime I'm navigating and I see the "busy" cursor for more than a few seconds, I go pskill that instance because I know that at least 95% of the time, once WE enters that state it's going to sit there for minutes while doing that, being 100% frozen and chewing up resources like mad. Were that WE were the only such example... Vista itself at times becomes catatonic... VS05 is so buggy on Vista as to be almost unusable... At times on Vista and in response to such heavy-weight tasks as opening a file or switching views/windows, VS05 will start chewing up all available cycles and yet will still go away for minutes or even tens of minutes at a stretch, being completely unresponsive and basically bringing the machine to it's knees.

Yep, they did the shuttle the same way they got the bomb. Except in the shuttle's case they didn't have to steal the plans, they simply bought them outright. Having been married to a Russian and having spent a lot of time in Russia and on Russian aircraft, and knowing their general approaches to things and their quality control the way I do, I wouldn't want to be in the same state as a launch of the darned thing.

I used to use/maintain/extend an inhouse set of data acq and math libs. The @#@# who'd written them was too lazy to type meaningful variables names and in general liked compact code. The end result was tens of thousands of lines of dense, nearly indecipherable code wherein almost all the variable and function names were one or a few characters (he often started at a and went through z, then A through Z, etc), function calls with side effects nested N deep, etc, something like: z = a(bB((c ? f : gg)) * Z(c + x); /* Note the embedded side effects */ It was a mess. The guy had been promoted because the libs *did* work well, but they caused me one bad review because it took me a month or more to even begin to understand that mess of obscure code. I finally transferred out of that group, and it was only after the second person to take over that role nearly failed that management started listening to the hapless victim, by then months late and way over budget. Morons. Why is it that so many managers reward naked self-promotion and ambition, whilst often punishing the very people who are saving their bacon??? I think a big part of this is left-over from the days when C and later C++ compilers were not much more than thin layers over assemblers, and tricky programmming tricks could equate to significant perf gains. Those days are long gone and optimizers are in general far "smarter" than most programmers ever will be. There are things to avoid that trip up the optimizers, but most of those are structural and have little to do with using cute, complex, obscure, or fancy statement constructs.

IMO: MFC should have been obsolete years ago. I doubt Win32 is going anywhere. .Net is a better app layer than MFC, IMHO. Having contracted at MS, I can say that at least in the OS and other lower-levels, C++ and Win32 are pretty much here to stay. I heard talk around the halls that XMAL + WPF are here to stay and will become the new MFC/.Net over time. However I, like many others, am skeptical. Personally (this is pure conjecture) I think MS is hoping and believing the "Everything Everywhere Live" (Windows Live, MSN LIve, Live Live, Your-Credit-Card-To-Our-Subscription-Server-Farm Live, etc ad nauseum), apps-through-web-based-subscritions movement is going to take off. If that be the case, XAML + WPF do make some sense. But as others have noted there's a lot of issues left to be resolved before Joe Accountant is going to trust the company farm to "Excel Live" with his data in an MS server farm somewhere and held ransom by BillG. "We're sorry your high availibilty ultra-premium business storage is offline. Your wait time will be 32.6 days. For only $500 per fifteen minutes, we can escalate your call to a live level N LiveGuru support engineer, and hopefully recover your data over in Moses Lake. Message 6."

The intentional map distortions may have predated the Soviets, but the Soviets took it to new levels. Russia is a mess, they intentionally avoided an address system that makes sense, and requires that one has local area-specific knowledge in order to intepret and find an address.few

I'm on my 2nd iPod and love them, but it's clear that in terms of bang-for-buck/feature-count/capacity-for-dollar, Apple/iPod is more spendy. I believe the other poster nailed it, Apple markets a streamlined experience that actually removes features, capabilities, and capacity in exchange for an overall slick experience. BTW, I will not be buying an iPhone. It seems Apple made the battery an integral part of the phone and not end-user replaceable. Given Apple's rather pathetic record when it comes to right-sizing battery capacity, I am certain they are going to have battery problems with the iPhone and may well end up getting sued over battery issues (again.) That, and given that the phone is essentially one large (relatively power hungry) display (probably twice the acreage or more as measured against the iPod etc), and that the overall form factor is small and ergo the battery must be small, I have 0.0% confidence in Apple having gottent the battery right. Maybe by the time it gets to a V2 or better...