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 …

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 …

Update 3/17/07: A new version of the code and assembly is linked from the article below which fixes a bug with the calibration data.

My latest article has been posted on MSDN's Coding4Fun.  This time I have created a fully managed library to use a Nintendo Wiimote (and all current extensions) in C# or VB.NET.  You will find a description of what was done, source code for the fully managed library, a test application, and compiled libraries for you to start using immediately.

As always, if you have questions, problems, feature requests, etc. please contact me and let me know.  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.

Head on over and check it out!