First though it might be interesting to investigate if we can continue to use the same approaches that we have used in Windows Forms now that we are dealing with WPF Windows. Let's add a second Window to the project and see the options.

 In Orcas Beta 1 the 'Add New Item' menu pane looks like this:

 If you are using the VS 2005 WPF Extensions it is slightly different, but equally straightforward.

 The resulting display in the Visual Studio IDE is pretty much the same as for the original initial window, Window1.

 At the top of the screen you have the WPF Design pane - the Window has the single celled Grid docked in it. The bottom part of the screen has the XAML Code pane, and the XAML code so far comprises the declaration of the Window itself, a class declaration, a couple of namespace declarations, some properties for the Window - Title, Height and Width - and finally the declaration of the Grid.

 WPF Window Default XAML Code

Before we go on to the look at access between Windows this might be a good time to look at them before we move on, as we skipped over this the first time round. If you are just interested in showing and accessing multiple windows at this stage, feel free to skip to the next section.

 The XAML code you see in the screenshot is created by default each time you add a new WPF Window to a project.

 The first line:

creates a class in the XAML code named "Window2". The underlying purpose of this class is to enable the compiler to link the XAML code to the VB code-behind. Remember the use of the "x" prefix we used earlier when adding a Name property to a control so that the control appears in the xaml.vb code-behind combo of available controls? Without this class declaration you wouldn't be able to wire up the XAML UI to VB event code.

 If you were to delete the class declaration you wouldn't get an error message. Well... not until you tried to do any kind of event handling, that is. Note that if you were to delete that code the automatically created Window2.xaml.vb file still remains in existence and is still visible in the Solution Explorer. However, it would be the boniest of skeletons as there would be no Window events available from the right hand combo:

Additionally, another important file, Window2.g.vb, is not created. This file is not shown in Solution Explorer in the Beta 1 edition, even with "Show All Files" selected. The xaml.vb file and the g.vb file contain the two parts of the Partial Class, in this case the class named "Window2".

 Window2.g.vb is created automatically and can be accessed where it sits in the Project's obj/Debug folder. The typical Window g.vb file looks like this:

 The next two lines of XAML code:

two XAML Namespaces are defined. For now, it's enough to know that the first of these namespaces contains the core WPF classes. The second one maps to the XAML namespace. Note the "x=" prefix used when pointing to this namespace. This is the key which allows you to insert those "x:..." code items that link your XAML code to the VB code-behind.

 The following line:

will now be familiar to you as it simply sets three basic properties of the Window. (I think I've previously mentioned that the Caption/Text property of the Window - i.e. the text that appears in the Windows Title Bar - is now known as the Title property.

With this second Window now created and available in the Visual Studio IDE let's look at some ways of linking it to the first one.

 Showing A Second Window

 One of the first questions I asked was "Can I still use the Show and ShowDialog methods that I'm familiar with from WinForms?" - i.e.:

  The answer ? :-

  Yes!

 So, for basic Show and ShowDialog actions you can stick to the WinForms approach that you will be familiar with.

 And what about the familiar problem of referencing the various windows from each other? Can we still use the WinForms approaches for this too?

Again, yes. One popular way is to add a module to the project and create variables with Friend scope. Something along these lines:

 WPF Windows don't have a Load event; their nearest equivalent is the Loaded event. So you can use this to assign Window1 to the MyWin1 variable:

thus enabling you to access this startup window from any other window in the project (as we will see shortly).

 In a similar way you can now edit the Window1 GoButton's click event so that a new instance of Window2 is created and assigned to that previously prepared MyWin2 variable. This approach again means that Window2 can be accessed from anywhere within this project:

 Clearly, you need to add the ExitButton to Window2 before this will compile. Either drag one from the Toolbox to the Design pane or create one in XAML yourself.

 And as you already have a Friend variable holding a reference to Window1, you can pass something back to that Window from Window2. Maybe a message to be shown in that currently redundant Label:

 So the bottom line on multiple windows is that you can continue to use most of the approaches you have used for WinForms in the past. As far as I can tell, the default form instance - much loved by Classic VB developers, dropped (to a chorus of Boos) in VB.NET 2002 and 2003, and reinstated in VB 2005 - is not available in the same way in WPF. (So it is still available in standard Windows Forms in VB 2008 if that's an approach that you like to use).

 As we will see later, there are several other multiple display options exclusively available in WPF.

 Label Limitations
 There is one slight glitch with the code snippet above. If you actually run it exactly as-is you will find that the text in Label1 is truncated.

Of course, this is an easily surmountable problem. We could increase the width of the label or insert a carriage return in the text or adopt one of several other fixes. The reason I created this problem was simply to highlight a minor shortcoming in the WPF Label control. Unlike its WinForms Label cousin it doesn't have an Autosize property.

 This being WPF, of course, with its enhanced layout mindset the label has a default width setting of "Auto". If the form was made to be slightly wider - either by the developer or by the user - then the label will stretch in proportionate to the grid cell in which it is contained and all the text will eventually become visible:

 This might not always be an acceptable fix. So let's see what WPF can offer us as an alternative.

  The anwer is the WPF TextBlock. The name is self-explanatory. This control is not available from the Toolbox by default (at least not in the Beta 1 version). Attempting to add it in the usual way by selecting "Choose Items.." from the Toolbox unfortunately kept crashing the IDE in my Beta. I'm sure this will be fixed in upcoming versions. However, with our newly found XAML skills we can quickly and easily create one in code.

 Just to remind you, it isn't necessary to hand code all the XAML shown. Once you have entered the TextBlock start and close tags you can set properties in the IDE's Property Window if that is your preferred way of working. I'm surprised to find that already I am just as happy to hand code it - this may be partly because the Properties Window in Beta1 is not very intuitive. I do miss that alphabetical listing!

 As you can see from the snippet above, the TextWrapping property is available for the TextBlock and this is set to "Wrap".

We now change the code in Window2 so that it pastes the text message into this block: (I've added an occurrence counter just to make the extra effort worthwhile and to extend the length of the string even further) :-

  And the TextBlock will display our text neatly wrapped and centered.

  There are still some settings, e.g. minimum sizes that we could change so that the text remains visible even when the form size is decreased but I will leave that for you. We have already done something similar with other controls.

  If you are wondering if it is possible to put a border round the TextBlock, the answer is of course that it can be done ... and of course can be achieved in more than one way. We will cover this in a later section.