It isn't as easy as you might think!

I decided to blog this rather than make it a regular article because the new version of Visual Studio will be coming out soon and (Hopefully!!) Microsoft will fix this. But in the meantime, renaming the startup window in a WPF application is a multistep operation that you have to do by hand. We're used to having Visual Studio do all this for us, so it might catch you by surprise.

To follow along, start a new, standard WPF application. Notice that the main window is assigned the uninspiring name Window1 in Solution Explorer. If you want to give it a more meaningful name, such as MainWindow, it's reasonable to start by simply renaming it. So right-click on Window1.xaml and select Rename. The paired .vb file is renamed and if everything was done the way it should be in Visual Studio, that would be all you had to do. But, No-o-o-o-o! There's more.

If you double-click Application.xaml, you'll see that the StartupUri is still Window1.xaml. That will crash. (When you change it in the project Properties, it does change this automatically.) Change that next.

Now open the code window for the newly renamed MainWindow.xaml. Although the name was changed, none of the internal references are changed along with it. Window1 in the Title attribute won't make your system crash, but it doesn't look good. But the Class="Window1" attribute really needs to be changed. Change both of those next.

Finally, open the code window for MainWindow.vb. Note that this class still has the wrong name too. Change it to MainWindow.

For good measure, you might want to run the project just to save the files and make sure nothing is still wrong. Whew!!

If you're not familiar with the phrase, Bill Gates famously used it a lot when he would demo software. It means that Microsoft had an internal policy of using their own software.

I was recently working on a programming problem in WPF so I googled one of my own articles about it and copied the example code into a project to run it. Surprise! It didn't run! It didn't do anything.

I know that I tested the software before I posted it. That's one of my internal policies. So what went wrong? My current theory is that I tested a slightly more complex version and then "cleaned it up" to make it easier to read by deleting unnecessary code. Except that, the code I deleted was necessary after all. Figuring out why turned out to be fun! WPF is so much fun! Almost as much fun as giving yourself an operation by looking in the mirror.

In any case, Part 5: A First Introduction to WPF and XAML for Visual Basic Programmers is expanded and retested now. You might want to start at the beginning. The link is on the first page of the link above.

This may be a pretty obvious idea, but it hadn't occurred to me before.

W-a-a-a-y back in 2005, I wrote a blog, Hungarian Notation - Good Idea?, in which I noted that Microsoft wasn't consistently recommending a naming style called Hungarian notation anymore. In brief, Hungarian notation names variables according to their type. "txt" would be a text variable; "dbl" would be double and so forth.

If you go back through the examples I code in the articles here, you will see that I have never had a consistent naming sytle. Quite frankly, I name 'em according to the mood I'm in at the moment. I usually use a descriptive name based on camel case: theFirstVar, theSecondVar, and so forth. (In my first programming job with IBM, many many years ago, I can remember using variable names based on variations of the name of the love of my life. That was a good lesson in what not to do. Maintaining the code later was not only embarrasing, it was really confusing.)

That old blog has consistently attracted a comment every now and then over the years and just yesterday, "Matt" left this comment:

"If I'm looking for a textbox and can't immediately remember exactly what I named it, I can type "txt" and Intellisense shows me everything beginning with "txt" and I can find the textbox I'm looking for without having to return to the designer. If the textbox were named "DisplayNameTextbox" and I thought I named it "NameTextbox", then I would have no easy way of finding it with Intellisense and would waste my time in the "N" section.

Good point! Check the graphic above to see how that works.

But the original reason for Hungarian notation was to avoid type conversion errors. Since VB6 declared everything as a "Variant" type, inefficient code and sometimes nasty bugs could be created by thinking you were working with a string when it was actually an integer. VB.NET doesn't have this problem since it features "strong typing". (Although, we're starting to get close to what we had in VB6. I can use "Option Explicit Off" and then simply code myVar = "ABC" with no variable declaration at all.)

It seems to me that, since avoiding type conversion problems is no longer a motivator, you might be better off simply using this idea to group your variables according to some requirement specific to your system. For example, you might have two GDI+ Graphics objects in the same program and you need to make sure that you keep the objects, such as Color, organized.

In The Trouble With InputBox, I pointed out that InputBox wasn't really a very good way to input data to a ListBox and I pointed out that it also had a fatal flaw - there wasn't any way to tell the difference between blank input and the Cancel button.

It turns out that this isn't quite true ... About Visual Basic reader "SmetsRoger" pointed out that his whole night school class had worked on this problem and had discovered a solution. I checked it out and, yes, the solution does work ... for now. But I wouldn't use it. The reason it works now and why I still wouldn't use it is a fascinating investigation that you can read about in a followup article, Fixing the InputBox.

Thanks much to SmetsRoger for sending this one in! It was fun!