I will be presenting Interfacing External Hardware Using Managed Code and Microsoft Robotics Studio on Thursday, April 19th at the NYC .NET Developer's Group monthly meeting, which begins at 6pm.  I'll be showing off some cool toys from the Phidgets people (an RFID reader, interface kits, sensors, etc.), how to control hobby servos and motors via a PC, and wrapping up with an introductory look at Microsoft Robotics Studio.

Come out and heckle!

Here's an important safety tip that I wish I knew before the 4 hours I wasted on figuring it out.

When building a model in 3D Studio Max (or likely every other modeling package in the universe), and then exporting it to a DirectX .X file via the Pandasoft X file exporter or kilowatt X file exporter plugins, ensure that the model has no meshes named with a space or period (or likely other characters).  This will cause the XNA importer and DirectX Viewer (or likely every other .X file importer in the universe) to fail with a very informative error like "Parser error" with no further information.

We had a model that was working great.  My artist decided to tweak some things and add some new meshes, at which point the new version of the model stopped working.  At first we blamed it on the new parts that were added, then textures, then the exporter, then....who knows.

Finally, after exporting the original model as a .X and the new model as a .X and comparing, I found that the mesh names that had spaces in them were not being exported correctly.  One area would reference the name with an underscore, and another would have the actual space character.  Fixing the names in 3D Studio Max and then exporting again fixed everything.

I have been accepted as a new blogger by the good people over at CodeBetter.com.  If you've never been there, you're missing out on some great technical content.

My plan is to cross-post my technical content from this site to my new CodeBetter.com blog to reach a much wider and varied audience.  All non-professional/non-technical will remain here only.

This blog isn't going anywhere and will be the superset of all content between the sites.  The CodeBetter.com blog will be the subset that is technical.  You choose where and what you'd like to read.

Enjoy, and thanks to John Papa and the folks at CodeBetter!

My latest article is up on MSDN's Coding4Fun.  Take a look and download a fun application to annoy your friends and co-workers on April Fools' Day.

As always, questions and comments welcome.  If it's a question or comment that could benefit the masses, please create a new post over on the forum and I will reply there.

Warning.  Rant coming...

I was working on a project last week that included code that looked sort of like this:

public bool SomeMethod()
{
    try
    {
        // do some lengthy, involved, *critical* process that, 
        // if it fails, will cause the rest of the application to fail *forever*
        // as it leaves a required, persisted resource in a corrupted state
    }
    catch
    {
        return false;
    }
}
public void SomeOtherMethod()
{
SomeMethod();
}

Of course, when I was debugging an issue in this application, SomeMethod was failing, yet I had no idea because the author of the code decided to not only throw away the exception that was being thrown, but not bother to check the return value of SomeMethod after it was called.

So here comes the rant.

Stop it!  Stop doing this!  Stop catching exceptions and either doing nothing with them, or throwing them away!  It's an exception handler!  If you're not going to handle the exception, don't catch it!