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.