Why All My Windows Forms Programming is in Visual Basic Lately
In the Windows Forms documentation team, we need to be skilled in both C# and Visual Basic, as we are tasked with writing code examples for both languages. Traditionally, I've biased my work toward doing C# first, and converting to Visual Basic later. C# always struck me as a more "professional" language somehow.
Lately, however, I've found VB becoming my new bias. Heck, I'll admit it - I love the language. No, that's not accurate. While I like the language, what I love is the VB experience provided in Visual Studio.
What's there to love about it when it comes to Windows Forms programming? Surprisingly, several of my high points have to do with the new My object, which I've spent a good two years looking down upon.
- The Handles keyword. No need to stuff event handler code in a code-behind or in the Form_Load event - the compiler does the dirty work for me.
- Statement auto-completion. Matching up curly braces is nice. Having my Sub and If statements completed for me is even nicer.
- My.Settings. Any settings I create using the new Windows Forms application settings feature show up as properties on this class.
- Stuffing My.Application with global goodies. Right-click your project and select Properties. On the Application tab, select View Application Events. Ta-da - you now have events for handling app startup and shutdown, and for extending the My.Application class to your heart's content. I've made extensive use of this feature in my latest apps.
- My.Resources. Again, all resources show up here, making resource usage dirt simple.
- My.Computer.FileSystem. Hallelujah! A single point of access to the file system, where most common tasks can be accomplished with one or two well-named method calls! No more attempting to remember which XXXWriter class I have to create, and on which subclass I need to create it.
I'm not saying I'll never write another lick of C# again. Quite the contrary. But I have a new appreciation for the VB experience.