Leave 'em Checked!

I know, I know. When you get a warning you don't understand from Code Analysis in VS 2005, the easiest fix is to uncheck the rule that is causing the problem. Click. No more problem! Or, you could right click on that little bugger and select "Supress Message(s)". Yeah, you could do that. I wanted to do that. But I didn't. I may have wasted (not really) several hours on things that I may not actually need now, but my Code Analysis runs clean! How satisfying!

So, what did I learn? Today's little hunt across the Intertron helped me with localizations and the resources that go with them. Do I need to make my applications region specific with various languages--not right now. Will I ever? Who can say? The point is, I found one more way to make my code easier to change, if I need to later on down the line. If not this application, maybe the next one...or the next one. Enough, JD, on with some actual information.

So, the Code Analysis error I was getting went something like this:
Warning : CA1303 : Microsoft.Globalization : Form.Subroutine():Void passes a literal as parameter 1 of a call to Control.set_Text(String):Void. Retrieve the following string argument from a resource table instead: 'Browse' Form.Designer.vb

OK, I get it. It doesn't like the literal string "Browse" in the Form.Designer. "Avoid magic strings", just like McConnell says.

The deadends:
1. Well, I could go in and change them all to constants so that all my strings are in the same place and I get some reuse out of them (replace all the "Browse"es with one const). Bad idea. Don't mess with the Form.Designer because your changes might not stick when you start mucking around with the actual Form.
2. Okay, how about creating a bunch of resources in the MyProject -> Resources tab. Then, I just refer to the strings by the variable name using My.Resources. Well, this is better, but you still have to put the variables in the Form.Designer file. I found it rather strange that I couldn't just type the My.Resources.stringVariableName directly into the control properties so that I could avoid the Form.Designer, but the reasons for this become clear later.
3. Next, I tried to stick them in the settings file. See, you can set the Text of the control in the (ApplicationSettings) property to any setting that you create. Now, this is a bit more promising. However, remember Code Analysis told us to use a 'Resource'. Plus, I'd have to create a setting for every bit of text on the form. Not so bad if you are doing it all along, but it kind of stinks when you already have a bunch of strings.

Well, I did a bit more digging, and it's easier than I thought. The whole rational for this is that you create a 'Resource' that has all of your strings in it. Then, when you need to add a new language, you just make another 'Resource' with all the same strings (in the new language), and your application knows what to display by the user localization setting. You don't have to make a bunch of different forms for a bunch of different languages. The other great thing about this resource, is that it stores all of the control locations as well. So, if things don't quite fit with a new language you are working on, you can move the controls around so that they do without affecting the other languages. Neato!

The kludged solution:
If you click on the Form, and check out the properties, you'll notice one called 'Localizable'. Change this guy to 'True', and your results are twofold. (A) VS 2005 generates a .resx resources file attached to the Form (toggle "Show All Files" in the Solution Explorer to see it) that has a whole bunch of strings that you might want to translate when porting to another language. (B) No more "Retrieve the following string argument from a resource table instead" errors from Code Analysis! Then, if you need to start working on different languages, just change the 'Language' property to the new language, and VS 2005 will generate a new .resx resources file to track the differences.

Do I know how to actually use the localization resources that I created? Nope! Not yet! Remember, this is a journey to kludgeless solutions. I'm obviously not there yet... The point of this post was to say "Don't ignore the Code Analysis Errors!" Fix them! Figure out what they mean! Don't shrug them off! Take every opportunity to learn more about application development. Little steps along the way are better than jumping off a cliff later.

First Kludge

So. This is it! My first blog post. I've been wrestling with the idea of starting to blog, but I could never figure out what exactly I would be talking about. It's a good thing Hoakie came a long and kicked me in to action. Little did he know that I know just enough about a few things to be dangerous.

Ok, here's everything you don't want to know about me:
I am greengreengreen when it comes right down to it--but technically I'm still a software developer. I've spent the past 3 years writing flash memory test code in C++ for a little known US based memory maker. Actually, the only US based memory maker. The test code ran on a DOS based tester, so my experience writing applications is minimal at best. For the past six months, I've been attempting to learn Visual Basic, .NET, and TDD. I've got one kludged app under my belt, and cringe whenever I think about it. Oh, and if I had a nickel for every time I cringed while reading Code Complete (thinking of my old C++ test code), I'd have a few dollars at least.

I hope that my role on Kludgeless is one of the naive young grasshopper. I'm going to ask a lot of dumb questions that everyone who knows anything about programming already knows. Hoakie and I will hopefully have some blog discussions that illuminate our choices for TDD methodologies, and illustrate why we've made them. In this way, I hope to gradually become a much better programmer, and maybe help someone else along the way.

So, there it is. Boring, I know. Hopefully we'll get some more interesting posts up soon, and maybe--just maybe--get some traffic other than our own...