First, thanks to About Visual Basic reader "Chris" for suggesting that I upgrade the WPF tutorial to include WPF animation. The tutorial really was incomplete because using the WPF animation classes is the right way to do something like varying the opacity of a Label component.

In addition to demonstrating how to do animation, the new addition to the tutorial, Part 7 of the tutorial, Storyboards are introduced (since complex animations will require a Storyboard) and the code developed is downloadable.

Reader "Mark" left a comment to my recent blog ...

... Hungarian Notation Revisted that included a link to a great article written by the authentic programming guru Joel Spolsky about Hungarian Notation. (Scroll all the way to the end to find Mark's comment.) I found both to be really interesting. And for anyone who doesn't make it all the way through Joel's essay to the end, there is a link to Charles Simonyi's original paper at Microsoft's site in it: http://msdn.microsoft.com/en-us/library/aa260976(VS.60).aspx

I especially love Joel's down-to-earth descriptions.

"you spend the next day writing up coding conventions for your team and the next six days arguing about the One True Brace Style and the next three weeks rewriting old code to conform to the One True Brace Style until a manager catches you and screams at you for wasting time on something that can never make money"

Oh yeah! Been there. Done that. It got even worse in the "methology wars" of the 1980's and 1990's. Drawing the "wrong" kind of arrow in a modeling diagram could get you hung at sunrise in some programming shops.

Although Joel has written a much more thorough and well grounded explanation of Hungarian Notation, his bottom line conclusion is pretty much the same one that I have advocated here: Quoting one of my replies above: "I do think that being able to, for example, group all of the variables in an 'employee' structure (say ... maybe with an 'emp' prefix) might be handy."

But I think he still misses a key point, and that is because Joel doesn't usually think like a VB programmer.

Joel does recognize that language makes a big difference.

"When you see the code

i = j * 5;

... in C you know, at least, that j is being multiplied by five and the results stored in i. But if you see that same snippet of code in C++, you don't know anything. Nothing."

(There's a reason why C++ just isn't used that much anymore. Multiple inheritance is a problem, not a solution. That's why it's not part of .NET.)

The key to understanding why VB6 coders used to feel Hungarian Notation - the Petzold version - was important has to do with the unique advantages and disadvantages of VB6. And the "Law of Immediate Threat". If you're in a war zone, two threats that you face are: (1) Getting shot. (2) Getting hit by a meteorite from outer space. Either one can kill you. So, do you put your armor over your head or in front of you? The answer is obvious, but let's apply that to VB6.

VB6 featured a unique language feature called the "variant" type. Basically, a variant could be anything: integer, long, string - whatever. That was a huge convenience for beginning programmers and people writing quick and dirty apps, but for more sophisticated code, it could get you into real trouble with code that failed only once every five years. (The code usually failed on Christmas eve just as the year end accounting reports were being finalized so you could work throughout the night looking for the bug and miss most of Christmas day.)

The emphasis on Hungarian Notation as a "data type" indicator in VB6 is based almost completely on this particular bug. It's the one that plagued beginning programmers and people writing quick and dirty apps. They didn't have to worry about "Cross Site Scripting Vulnerability". (I can remember when THE FIRST VIRUS hit the web. The reaction back then was, "Gee! That's interesting! I didn't know you could do that!") (And while I'm discussing "type" - that's another word that just doesn't have a clear definition. It means different things in different languages and even in just one language - say, VB.NET - it's fairly loosely defined.)

Thanks muchly for the great link. I enjoyed it and I recommend it highly to all of my readers.

It appears that we're all going to have to know a bit more about multithreading in the new world of WPF.

I've just rewritten a lot of my tutorial on WPF (A First Introduction to WPF and XAML for Visual Basic). I've added a new part so it's now up to seven parts. You might want to check it out.

A question in the About Visual Basic Forum raised the flag that caused me to rewrite it. I wanted to show how the Opacity of a WPF Label could be varied. But to do a nice smooth transition, you have to use a Timer component. WPF doesn't include one, so I just "borrowed" the Timer from Windows Forms. When a Forum reader question got me looking at it again , I discovered that Microsoft's documentation states:

"This timer is optimized for use in Windows Forms applications and must be used in a window."

Well ... "must" is a little strong. It worked fine. (Much to my surprise, actually.) But I decided that I really ought to use the Timer from the System.Timers namespace instead and that DIDN'T work. In the process of figuring out why, I discovered that WPF is going to make us all a lot more aware of VB.NET's multithreading capability. Part 6 of the revised tutorial tells you why, but you will have to read Part 1 to get the most out of Part 6 anyway ... so why not read the whole thing?

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!!