What's New in WPF Beta 2?

If you've not noticed that today is a pretty significant day for Microsoft, you've either been offline from the major news sources or we've lost your attention altogether. I can't think of many occasions in my Microsoft career when we've released so many new things simultaneously. Here are a few links:

One resource in particular that I'd like to draw to folks' attention is the Windows Vista product guide - an extremely comprehensive overview of the several thousand new features we shipped in this release. It will hopefully dispel once and for all the myth that Windows Vista is just Windows XP with some tweaks to the user interface. Sure, it's been a rocky ride to this point, but Beta 2 marks a point where I'd say we are now firmly on the glidepath to release.

For those of you who are porting Avalon WPF code forward from our last release (the February CTP), you'll be pleased to know that the changes are mostly fairly trivial.
The big new feature is performance - this release shows the
benefits of the last three months of intensive efforts to reduce working set and
remove redundancies in the code. You should see significant benefits: as an
example drawn from my own experience, the
Allscripts
patient monitoring
demo that used to run embarrassingly poorly on my
two-year old laptop now runs super-smoothly: enough that I was able to
demonstrate it with confidence on the same machine at a CIO summit keynote a
week or two ago.

As I've gone through our portfolio of samples, there are a few changes that have stood out,
however: I've tried to enumerate most of them here.

Slider / ScrollBar Style Changes
We've made changes to the Track primitive class that is used in the styles of ScrollBar and Slider to make it simpler for tools like Expression to modify (you no longer need to create a new style to edit a single property on the Thumb or RepeatButton controls that make up a Track). The following sample code shows the new syntax:

<Track Name="PART_Track">

<Track.Thumb>

<Thumb Style="{DynamicResource
Slider_Thumb}" />

</Track.Thumb>

<Track.DecreaseRepeatButton>

<RepeatButton>

<RepeatButton.Resources>

<Style BasedOn="{StaticResource
Slider_RepeatButton}"

TargetType="{x:Type
RepeatButton}">

<Setter Property="Command" Value="Slider.DecreaseLarge"
/>

</Style>

</RepeatButton.Resources>

</RepeatButton>

</Track.DecreaseRepeatButton>

<Track.IncreaseRepeatButton>

<RepeatButton>

<RepeatButton.Resources>

<Style BasedOn="{StaticResource
Slider_RepeatButton}"

TargetType="{x:Type
RepeatButton}">

<Setter Property="Command" Value="Slider.IncreaseLarge"
/>

</Style>

</RepeatButton.Resources>

</RepeatButton>

</Track.IncreaseRepeatButton>

</Track>

Z-Ordering for Panels
This is the kind of change I like! We've added an attached
property for panels that allows you to control the z-order of elements contained
within them. The absence of this feature has been painful for a number of our
customers and partners (in the past, z-ordering was determined by the order of
objects in a collection, meaning that you had to remove an object from a
collection and re-insert it, with all the associated overhead of doing that).
It's great that we've been able to fix this in time for the first production
release of WPF. Simply check out the Panel.ZIndex attached property.

XAML Syntax Tightening
We've tightened up XAML syntax in a few places. One common example
where you may start seeing a build error is in code where you use x:Name inside
a subclassed container panel if you also use it in the subclassing itself. If a markup subclassed element (defined in one scope, aka the definition scope)

was used in another scope (aka the usage scope) and it had names on elements

under it in the usage scope, there exists a potential conflict of these names

wherein name fields would be created for these in the outer (usage) scope, but

the parser would actually register the names in the inner scope (since it would

implicitly acquire a namescope dynamically in the definition
scope). and give names to because we can't easily detect name clashes of this
kind at compile time.

Another XAML change is that resources can no longer be forward referenced.
For example, if you have a data template that references a control template with
an x:Key of foo, then foo must be declared before the data
template.

Windows Forms Integration
ElementHost and WindowsFormsHost
now contain a Child, rather than a
Children property, since they can only have one child (poor things...). A few of
the other methods like FirstChild are also removed, since they're no longer
necessary. This should be a straightforward fix.

Those are all the changes that I've run into so far - I'll supplement this
list if I come across anything else that's worthy of note. Let me know if you're blocked by anything else and I'll do some digging.