Communications of the ACM[^]:

Conceptually simple features take longer than expected to implement.

This statement is so true...

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

Like several of the others, I've never needed an "emergency coding pack". If I need to do any debugging in the field then I bring a laptop with my dev environment. However, one tool I use frequently is LINQPad[^]. Comes in handy for testing short pieces of code, or just making use of a public api for a quick script without needing to fire up VS. The Dump() method is useful for inspecting objects on the fly as well.

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

This is fine, although the

Claudiu Schiopu wrote:

catch (Exception) { throw; }

doesn't really do much. You can just have the

try

and

finally

blocks, and the code would effectively do the same thing.

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

Not quite an answer to your question, but expanding on Richard's suggestion[^] of a static class, I also recommend the getter methods generate the command, rather than hard-coding them all. Of course, this depends on how your commands are structured. For instance, if each command includes the length of the data, or ends with a checksum or CRC, it's typically best to calculate that value and add it to the command, rather than hard-coding it. If all of your commands are completely different and don't have any common fields like this, then ignore this post :)

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

Overall the new design is good, but as others have mentioned, the sea of white can be a bit harsh on the eyes. It'd be nice to have the option to select different themes (maybe a gray for instance). Of course, it may be difficult to find other colors that go well with orange ;P.

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

I'll admit I'm not familiar with Metro design standards, so maybe my suggestion should just be ignored, but here's my $0.02. Since the login fields are only visible while the mouse is hovering over the Sign In icon, it makes it difficult to use something like KeePass to auto-type the login. Granted, if I click the Login button, I can still get to a different screen with the login fields and it works, but it would be nice if this still worked from the other pages as well. Or even if the login fields stay visible after moving the mouse, and maybe the user to click outside the fields to dismiss the dialog? Dybs

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

OriginalGriff wrote:

IIRC none of the .NET Collections are intrinsically thread safe

Actually, .NET 4 introduced the System.Collections.Concurrent namespace[^], which includes a ConcurrentQueue. However, IIRC there's the potential for a delayed garbage collection - the queue keeps a reference to the object even after it's dequeued until it's been overwritten in the queue's buffer. This becomes more of an issue with a large-capacity queue. Our workaround was to use the Mono implementation of the ConcurrentQueue instead (it doesn't have this problem).

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

There's no "F-lock" key? I've seen some Microsoft keyboards that default F-lock on to enable all the secondary functions. Very annoying.

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

Also make sure that file doesn't already exist on your system and is not open by another program (or even your own).

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

Also make sure nothing else has the text file open when the scheduled task runs.

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

Does the task scheduler display an error code next to the task when it runs? Also, check the Application event log around that time and see if there are any errors (although as Eddy mentioned, it's a very good idea to catch any exceptions and log them for later debugging - but the Event Viewer might display the exception as well).

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

The CLR Profiler is definitely great tool for finding memory issues, but not so much for performance bottlenecks. ANTS comes in handy for those issues (although ANTS does have a memory profiler as well, but I like CLR better).

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

AspDotNetDev wrote:

The bottom right of the ANTS page shows awards, including "The Code Project Members Choice Winner 2011". :-D

So it does :)

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

I've been using ANTS from RedGate[^]. If you're on Windows 7, it also lets you attach to a running .NET 4 process and just profile what you want, rather than profiling from startup. One of my colleagues uses DotTrace from JetBrains (same guys who make ReSharper)[^]. I think it also lets you attach to a running process. They've both been great tools for us, sometimes one will show us something the other doesn't, so sometimes it's nice to have both.

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

Amazing, I wish I had time for cool projects like that.

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

I think foo would be zero, but that's just a guess. I think Int32.TryParse and Double.TryParse set the out parameter to zero if the parse fails, but I don't recall. If TryParse fails, I usually set the value to some known default that I can handle - I don't care what TryParse sets it to, especially is MS decides to change it down the road.

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

LINQPad is great. I use it all the time for testing small snippets, one-time mini-programs, and just playing around to figure out how to use a .NET feature. The Dump() method is particularly useful for getting a feel for the structure of an object you're not familiar with.

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

Assuming they're visible on the pcb, you could follow the traces from the power button to the ribbon cable connector, determine which wires in the cable are for that button, then find the corresponding pins on the mobo. But that sounds like more effort than I'd like to go through :) . Times like this make it nice to have a Asus P8Z68-V Pro/Gen3[^] that has power and reset buttons directly on the mobo.

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

Colin Rae wrote:

I'm not entirely sure how you could test that though

If you unplug the power button from the motherboard, you can short the two pins briefly to power it on (I typically use a flathead screwdriver ;P).

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen

Be careful when using BitConverter. It uses the endianness of your CPU, so if you're byte array is coming from a hardware device with a different endianness, your BitConverter results will be messed up. See BitConverter.IsLittleEndian[^] Dybs

The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen