You know what makes that even more amusing? You're actually correct! The ancient Inca used knotted strings called quipu[^] as a sort of calculator. :cool:

The CodeDOM stuff as mentioned by others might work. Another possibility could be Microsoft's new Project Roslyn[^].

Like most tech, there are good and downright wretched parts to it. Does it make sense on a phone? Absolutely. Big targets for touchscreen use. Normal behavior you expect for mobile apps. Does it make sense on a tablet? Yep, though there are flaws if they really intend you to use the tablet for both tablet and PC use cases. The desktop mode on a tablet is fairly useless. Normal Windows UI elements are just not designed or intended for our fat fingers. They need to have versions of Explorer, Task Manager, and other classic desktop apps that are designed for Metro. I'm sick of trying to touch/click on a Listview entry in Task Manager so I can close an app Microsoft is too shortsighted to let me close with a built-in Close/Quit button. To their credit, they are doing a good job with trying to create a consistent UI "language" or set of idioms you use to get around. In the same way that we're used to right-clicks and double-clicks, you swipe the left side to tab between apps, you swipe the right to get to the global settings and charms, and you swipe the top or bottom to get to app-specific features. There are also the usual scrolling and pinch-to-zoom gestures. That all seems to work pretty smoothly. Does it make sense on a console (XBox 360)? In theory maybe, but in practice it sucks unless you have a Kinect. With the new dashboard, I have this big wall of tiles that give me no info and take more controller movements to navigate. If you have a Kinect, I'm guessing it works a lot better. If you only use a controller, it's like navigating the on-screen keyboard all the time. In other words, a clunky nightmare. It feels like it takes an order of magnitude more controller inputs to get around now. Does it make sense on a desktop? Not really, at least for what most of us do on a desktop or laptop. Too many things on a desktop require precision navigation and action. I'm not doing word-processing or document creation or CAD drawing on a touch-interface like a phone or tablet. The granularity of the user's input is not small enough to match the granularity required by the activity. If I'm editing a word in a document and my finger or thumb covers the entire word, how am I supposed to get the cursor where I want it to be? I would need a screen the size of a table so I could get my finger or hand at the exact spot I want. Ok, so if I'm not needing tablet-style "casual" apps or games on my desktop, what does Metro give me? Not much I think. Navigation around the Metro UI with a mouse and keyb

Two other options to try are Umbraco[^] and Telerik's SiteFinity[^]. Both are free (or at least have free versions) and are much better supported than the others you listed.

Congrats man! I hope your plan goes off without a hitch! I pick up the ring for my turn at this next week. I feel like a little kid that can see all the presents around the tree before Christmas and can't wait until the time comes to open them. :-D

Anna-Jayne Metcalfe wrote:

As far as features go, so far I'm distinctly underwhelmed; I was hoping for far better C++ 11 support in this release (I mean, how difficult can features such as standards compliant range based for loops be?).

For what it's worth, Herb Sutter claimed in one of his sessions yesterday that the C++11 STL is fully implemented in VS2011. Apparently some of the C++11 language features took a lot longer to do than they expected (especially variadic templates) so they ran out of time.

Here's my observations so far from both the sessions at Build and playing around with it myself in a VM. (I checked out VS on the tablet they gave us, but immediately determined that only a masochist would even think about coding on a tablet). 0. There aren't a lot of new features. Most are subtle or only interest smaller segments of developers 1. It's as stable as you expect a pre-beta app to be. 2. Being restricted to Metro-style apps in the developer preview version sucks. 3. The integration of some of the features from VS2010 Power Tools is cool. 4. Being able to determine why DirectX rendered a particular pixel the way it did is very cool. Makes me wish I did graphics programming! 5. Having WinDbg integrated in to VS is awesome. 6. Integrating Expression Blend, or at least parts of it, for the XAML designer is a good thing. 7. For .NET developers, it's probably worth checking out the preview just to get familiar with the new async language features coming in the next versions of C# and VB. 8. More cool stuff is coming out in about a month with the Project Roslyn CTP. Project Roslyn is the work they're doing on the C# and VB compilers to open the compilers up and create APIs on top of the different steps in the compiler pipeline (syntax tree, symbols, emitting IL/object code, etc.). Anders Hejlsburg demoed user-created refactorings in VS, an interactive C# prompt, and C#<->VB converters in just a few lines of code.

Virtual machines are your friends, especially when dealing with pre-beta software from Microsoft.

Heh, tell that to Microsoft. They didn't release the session schedule until after yesterday's keynote!

Even though I just do .NET development for work, I'm seriously thinking about taking in one or two of the C++ sessions. The session list is a huge wall of text, so I still need to sift through which ones I want to go to.

I think you're supposed to, but my coworkers and I were just riffing most of the keynote. We're not big koolaid drinkers.

I hear you. But when I'm not paying for it and they give us free tablets, I can't complain.

So it looks like a bunch of you are watching the webcasts for the conference. Are there any other CPians actually attending the conference out in Anaheim? Interested in a meetup?

No, attending a school in/from a different state does not have to trump native sports loyalties. I'm a WI native living in MN and I've never cheered for the Vikings unless the Packers needed them to win in order to get to the playoffs. Of course, given the amount of talk about beer and food around here I don't know why you wouldn't want to be a fan of teams that are all about beer, cheese, and brats. :)

Your light bulb story seems similar to mine. I've had a couple of those CFL bulbs go up in smoke, literally. I can't think of any reason why this would happen other than crap power. It probably had something to do with the demise of 3 motherboards in my previous desktop too. Perhaps try a UPS or something else to clean up noise on the power lines? I think most surge protectors only kick in for big spikes, not generally poor line quality.

Our thoughts and prayers are with you! :rose:

As a WI native living in Minnesota, your daughter is officially my hero for the day. :-D

It looks like there is some broken HTML in one of the article entries on the ASP.Net Controls page (http://www.codeproject.com/KB/webforms/[^]) I've checked the page in multiple browsers and the article listings get cut short, with the final entry being Remove multiple items from ListBox [^]. The article summary picked up half of an HTML comment causing the rest of the entries to disappear and get munged up with the page footer. Here's the summary in question: <span id="ctl00_ctl00_MC_ArticleList_TSR_ctl00_ALR_ctl237_Dsc">There is no direct way to remove multiple selected items from ListBox when SelectionMode of ListBox is set to "Multiple". So there is a small solution to handle this situation.In following Example ListBox "lstCity" contains multiple cities and SelectionMode is set "Multiple".<!--List...</span>

It appears that the pager on the Q&A page is misbehaving. Regardless of what tab I'm on, the "next" link includes a "display=Mobile" parameter even though I'm viewing the page on a PC. I can reproduce the issue in Firefox, IE, Chrome, Opera, and Safari, so it's probably just a flag somebody flipped somewhere rather than a browser detection bug.

I had to do something very similar at a previous job. I set it up so that each data source (your sensor) had it's own reader thread. This thread parsed out the data and made note of other things like timing, etc. Each reader had a collection of data sinks, which was just a generic term for a consumer of the data. The reader would pass on each chunk of data to each data sink, which in turn would do whatever it wanted with the data. If you try something similar, you could have both your real-time graph and the file be data sinks. The real-time graph data sink could have it's own thread and 60-second circular queue. The file data sink could use its own queue or write the data directly to the file. Personally, I'd have the data file use another thread and queue and write data to the file in chunks of say 5-10 seconds or so. It's fast enough that you shouldn't lose too many data points if something goes wrong, and it's infrequent enough that things should not get bogged down.