Long Answer
The previous short answer provides some XAML to remedy the problem as well as a brief summary of what's causing it.
Loading a theme’s resources is not the same as changing the theme at the
OS level. Loading a theme’s resources
may cause adverse effects. From WPF’s
point of view, a large number of
implicit Styles are now present in the
application. These Styles may trump
other Styles. The bottom line is
treating a theme like an application
skin may not work without
refinements.
The following long answer will provide a more in-depth discussion of the problem. A few background topics will be covered first. This will answer some of the peripheral questions asked and it will also provide a better basis for understanding the issues at hand. After that, individual aspects of the problem will be dissected and addressed with an effective debugging strategy.
Theme Versus Skin
This was great question partly because hundreds of bloggers and forum threads recommend loading a theme from file as a way of “changing your theme”. Some of the authors making this recommendation work at Microsoft and many of the authors are obviously high caliber software engineers. This approach appears to work much of the time. However, as you noticed, this approach didn’t exactly work in your scenario and required a number of refinements.
Some of this problem stems from imprecise terminology. Unfortunately, the word theme has become hopelessly overloaded. A precise definition for theme that would avoid confusion is simply the system theme. A system theme defines the default appearance of Win32 visuals on the machine. My OS is Vista. My installed themes are located at C:\WINDOWS\Resources\Themes. In that folder are two files: aero.theme and Windows Classic.theme. If I want to change the theme I go to either [Personalize | Theme] or [Personalize | Window Color and Appearance | Color scheme]. Although it's not immediately obvious, the options I can select from all boil down to either Aero or Classic plus some additional refinements. Because a WPF window renders its client area rather than compositing a bunch of Win32 controls, the client area will not automatically respect the theme. The theme assemblies (e.g. PresentationFramework.Aero.dll) provide a basis for extending theme functionality into WPF windows.
The more general definition of theme is any look and feel configuration, at any level of granularity (OS, Application, Control). When people use the general definition, there is the potential for various degrees of confusion. Note that MSDN switches between the precise definition and the general definition without warning!
Many people would say you were loading an application skin, not a theme. Either word is arguably correct, but I would recommend this mental model simply because it causes less confusion.
So, how do I ensure that my app always
uses the Aero theme…? [emphasis
added]
Again, it could be said you are loading Aero’s resources as a skin. Specifically, you’re loading the ResourceDictionary located inside PresentationFramework.Aero.dll. Those resources were previously given special treatment as they were default resources. However, once inside the application, they will be treated like any other arbitrary collection of resources. Of course, Aero’s ResourceDictionary is comprehensive. Since it will be loaded at the application scope, it will effectively hide every default Style provided by the theme (Luna, in your case), plus a few other Styles, which is causing the problem. Note that ultimately, the theme is still the same (Luna).
As alluded to above, the theme is involved in Style precedence, which is itself a form of Dependency Property precedence. These precedence rules greatly demystify the observed behavior in the problem.
Explicit style. The Style property is set directly. In most scenarios,
the style is not defined inline, but
instead is referenced as a resource,
by explicit key…
Implicit style. The Style property is not set directly. However, the
Style exists at some level in the
resource lookup sequence (page,
application) and is keyed using a
resource key that matches the type the
style is to be applied to…
Default style, also known as theme style. The Style property is not set directly, and in fact will
read as null... In this case, the
style comes from the run-time theme
evaluation that is part of the WPF
presentation engine.
This blog entry takes a much deeper look at style versus default style.
.NET Assembly Inspection
This was also a great question partly because there are so many moving parts. Without an effective debugging strategy it will be almost impossible to understand what’s going on. With that in mind, .NET assembly inspection is a natural place to start.
From WPF’s point of view, a theme is essentially a ResourceDictionary serialized as BAML and embedded in a regular .NET assembly (e.g. PresentationFramework.Aero.dll). Later on, it will be necessary to view the themes as plain XAML to verify behavior in the problem.
Fortunately, Microsoft provides the 4.0 themes as XAML for developers’ convenience. I’m not sure if pre-4.0 themes are downloadable in any form from Microsoft.
For general assemblies (including pre-4.0 theme assemblies), you can use the (previously free) tool Reflector with the BamlViewer plugin to decompile the BAML back into XAML. Although not as flashy, ILSpy is a free alternative with a built in BAML decompiler.
.NET assemblies are littered throughout your hard drive and it’s kind of confusing. Here are their paths on my machine, which I sort of have a gut feeling for and sometimes manage to remember without trial and error.
Aero 3.0
C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\PresentationFramework.Aero.dll
Aero 4.0
C:\WINDOWS\Microsoft.NET\assembly\GAC_MSIL\PresentationFramework.Aero\v4.0_4.0.0.0__31bf3856ad364e35\PresentationFramework.Aero.dll
What is the PublicKeyToken for version
4 (or how do I figure this out)?
The easiest thing to do is use Reflector. The PublicKeyToken is the same as before: 31bf3856ad364e35
Additionally, sn.exe (from the Windows SDK) can extract assembly information.
On my machine, the command is:
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin>sn.exe -Tp "C:\WINDOWS\Microsoft.NET\assembly\GAC_MSIL\PresentationFramework.Aero\v4.0_4.0.0.0__31bf3856ad364e35\PresentationFramework.Aero.dll"
Loading Themes as Skins
Should (the PresentationFramework.Aero
reference) be updated to version 4.0?
Most definitely. The DataGrid did not exist in the .NET FCL prior to 4.0. There are several ways to confirm this, but the most intuitive one is that, by your own admission, you previously accessed it via the WPF Toolkit. If you choose to not load PresentationFramework.Aero 4.0 in App.xaml, Aero’s DataGrid Style won’t be in the application resources.
Now, it turns out it doesn’t even matter. I’ll use the original XAML, break in the debugger when loading, and inspect the application-scoped resources.
As expected, there are two ResourceDictionaries in the application’s MergedDictionaries property, and the first ResourceDictionary is allegedly the 3.0 version of PresentationFramework.Aero. However, I see there are 266 resources in the first ResourceDictionary. At this point, it just so happens I know there are 266 resources in the Aero 4.0 theme, and only 243 resources in the Aero 3.0 theme. Moreover, there’s even a DataGrid entry! This ResourceDictionary is, in fact, the Aero 4.0 ResourceDictionary.
Perhaps someone else can explain why WPF is loading the 4.0 assembly when 3.0 was explicitly specified. What I can tell you is if the projects are retargeted to .NET 3.0 (and the compile errors are fixed), the 3.0 version of Aero will be loaded instead.
As you correctly deduced, Aero 4.0 should be loaded anyway. It’s just useful to know what’s going on while debugging this.
Problem #1: Aero’s DataGrid Style is not Being Used
The DataGrid in this application will have zero or more Styles chained together depending on how you configure Style.BasedOn properties.
It will also have a default Style, which, in your case, is embedded in the Luna theme.
I knew just by looking at the original XAML there was a Style inheritance issue. The big DataGrid Style with ~20 Setters does not set its BasedOn property.
You have a Style chain of length two and your default Style is from the Luna theme. The DataGrid Style in Aero’s ResourceDictionary is simply not being used.
There are two big questions here. First, how can something like this be debugged in the first place? Second, what are the implications?
Debugging Style Chains
I would recommend using Snoop and/or WPF Inspector to debug WPF issues like this.
Version 0.9.9 of WPF Inspector even has a Style chain viewer. (I must warn you that this feature is currently buggy and not very useful for debugging this part of the application. Also note that it chooses to depict the default Style as part of the chain.)
The power of these tools is their ability to view and edit values of deeply nested elements at run-time. You can simply mouse over an element and its information will immediately surface in the tool.
Alternatively, if you simply want to look at a top-level element like the DataGrid, name the element in the XAML (e.g. x:Name="dg"), then break in the debugger when loading and put the element’s name in a Watch window. There you can inspect the Style chain via the BasedOn property.
Below, I’ve broken in the debugger while using the solution XAML. The DataGrid has three Styles in the Style chain with 4, 17, and 9 Setters respectively. I can drill a little deeper and deduce the first Style is “DataGrid_FixedStyle”. As expected, the second is the large, implicit DataGrid Style from the same file. Finally, the third Style appears to be from Aero’s ResourceDictionary. Note that the default Style is not represented in this chain.
At this point it should be noted that there is actually no variation between each theme's DataGrid Style. You can verify this by taking the DataGrid Styles from their respective 4.0 themes, copying them into separate text files, and then comparing them with a diff tool.
In fact, a moderate number of Styles are simply identical from theme to theme. This is good to be aware of. To verify this, simply run a diff on the entire XAML held in two different themes.
Note that there are many different elements nested within the DataGrid (e.g. DataGridRow) and each has its own Style. Even though DataGrid Styles are currently identical from theme to theme, the Styles for these nested elements could vary. Based on observed behavior in the problem, it's clear that some do.
Implications of Original XAML not Incorporating Aero’s DataGrid Style
Since DataGrid Styles are identical across the 4.0 themes, adding Aero’s DataGrid Style to the end of the Style chain is, in this case, basically superfluous. Aero’s DataGrid Style will be the same as the default DataGrid Style (from Luna, in your case). Of course, future themes could always have variations with respect to the DataGrid Style.
Regardless of whether there are any implications, since you intended to incorporate the Styles from Aero, it’s clearly more correct to do so until there’s a specific reason to not do so (which will be discussed later).
Most importantly, it's just useful to know what's going on.
Style.BasedOn Only Has Meaning within the Context in which it’s Used
In the solution XAML, DataGridResourceDictionary.xaml works exactly the way you want it to work. It’s important to understand why, and it’s important to understand that using it this way precludes using it in other ways.
Let’s say the final Styles in DataGridResourceDictionary.xaml’s Style chains set their BasedOn properties to a Type key (e.g. BasedOn="{StaticResource {x:Type DataGrid}}"). If they do that, then they will inherit from an implicit Style that matches this key. However, the Style that they inherit from depends on where DataGridResourceDictionary.xaml is loaded. If, for example, DataGridResourceDictionary.xaml is loaded into a merged dictionary right after Aero’s resources are loaded, then its Styles will inherit from the appropriate Aero Styles. Now, if, for example, DataGridResourceDictionary.xaml is the only ResourceDictionary loaded in the entire application, its Styles will actually inherit from the relevant Styles in the current theme (Luna, in your case). Note that the theme’s Styles will of course also be the default Styles!
Now let’s say the final Styles in DataGridResourceDictionary.xaml’s Style chains do not set their BasedOn properties. If they do that, then they will be the final Styles in their respective Style chains, and the only other Styles evaluated will be the default Styles (always located in the theme). Note that this would kill your intended design of loading Aero as a skin and selectively refining parts of it.
Note that in the previous examples, if the final key was a string (e.g. x:Key="MyStringKey") instead of a Type, the same sorts of things would happen, but there would not be any matching Styles in the themes or in the Aero skin. An Exception would be thrown at load time. That said, dangling string keys could theoretically work if a context always existed in which a matching Style was found.
In the solution XAML, DataGridResourceDictionary.xaml has been modified. Styles at the end of each Style chain now inherit from an additional, implicit Style. When loaded in App.xaml, these will resolve to Aero Styles.
Problem #2: DataGrid.ColumnHeaderStyle and DataGrid.CellStyle
This is a nasty problem and it’s responsible for some of the strange behavior you saw. DataGrid.ColumnHeaderStyle and DataGrid.CellStyle get trumped by implicit DataGridColumnHeader and DataGridCell Styles. That is to say, they are incompatible with the Aero skin. Thus, they are simply removed from the solution XAML.
The rest of this subsection is a thorough investigation of the problem.
DataGridColumnHeader and DataGridCell, like all FrameworkElements, have a Style property. In addition, there are a couple of very similar properties on DataGrid: ColumnHeaderStyle and CellStyle. You could call those two properties “helper properties”. They map, at least conceptually, to DataGridColumnHeader.Style and DataGridCell.Style. How they actually get used though is undocumented, so we must dig deeper.
The properties DataGridColumnHeader.Style and DataGridCell.Style use value coercion. That means that when either Style is queried, special callbacks are used to determine what Style is actually returned to the caller (internal WPF code, for the most part). These callbacks can return any value they want. Ultimately, DataGrid.ColumnHeaderStyle and DataGrid.CellStyle are candidate return values in the respective callbacks.
With Reflector I can easily determine all of this. (If necessary, it’s also possible to step through .NET source code.) Starting in DataGridColumnHeader's static constructor, I locate the Style property and see it is being assigned additional metadata. Specifically, a coercion callback is specified. Beginning with that callback, I click through a sequence of method calls and quickly see what’s going on. (Note that DataGridCell does the same thing so I won't cover it.)
The final method, DataGridHelper.GetCoercedTransferPropertyValue, essentially compares the source of DataGridColumnHeader.Style and DataGrid.ColumnHeaderStyle. Whichever source has higher precedence wins. The precedence rules in this method are based on Dependency Property predecence.
At this point, DataGrid.ColumnHeaderStyle will be inspected in both the original XAML and the solution XAML. A small matrix of information will be collected. Ultimately, this will explain the observed behavior in each application.
In the original XAML, I break in the debugger and see that DataGrid.ColumnHeaderStyle has a ‘Style’ source. This makes sense as it was set inside a Style.
In the solution XAML, I break in the debugger and see that DataGrid.ColumnHeaderStyle has a ‘Default’ source. This makes sense as that value was not set in a Style (or anywhere else).
The other value to inspect is DataGridColumnHeader.Style. DataGridColumnHeader is a deeply nested element that isn’t conveniently accessible when debugging in VisualStudio. Realistically, a tool like Snoop or WPF Inspector would be used to inspect the property.
With the original XAML, DataGridColumnHeader.Style has an ‘ImplicitStyleReference’ source. This makes sense. DataGridColumnHeaders are instantiated deep down in internal WPF code. Their Style property is null and so they will look for an implicit Style. The tree is traversed from the DataGridColumnHeader element to the root element. As expected, no Styles are found. Then the application resources are checked. You have a string key ("DataGrid_ColumnHeaderStyle") set on the lone DataGridColumnHeader Style. This effectively hides it in this lookup and so it isn’t used. Then, the Aero skin is searched and a typical implicit Style is found. This is the Style that is used.
If this step is repeated with the solution XAML, the result is the same: 'ImplicitStyleReference'. This time, however, the implicit Style is the lone DataGridColumnHeader Style in DataGridResourceDictionary.xaml, now implicitly keyed.
Finally, if this step is repeated once again with the original XAML, and the Aero skin is not loaded, the result is now ‘Default’! This is because there are simply no implicit DataGridColumnHeader Styles in the entire application.
Therefore, DataGrid.ColumnHeaderStyle will be used if the Aero skin is not loaded, but will not be used if the Aero skin is loaded! As advertised, loading a theme's resources may cause adverse effects.
It’s a lot to keep straight and the names all sound the same. The following diagram recaps all the action. Remember, the property with the higher precedence wins.
It may not be what you want, but this is how the DataGrid works as of WPF 4.0. Taking this into account, you could theoretically set DataGrid.ColumnHeaderStyle and DataGrid.CellStyle at a very broad scope, and still have the ability to override the DataGridColumnHeader and DataGridCell Styles at a more narrow scope using implicit Styles.
Again, DataGrid.ColumnHeaderStyle and DataGrid.CellStyle get trumped by implicit DataGridColumnHeader and DataGridCell Styles. That is to say, they are incompatible with the Aero skin. Thus, they are simply removed from the solution XAML.
Problem #3: DataGridRow.Background
If the recommended changes up to this point have been implemented, something resembling the following should be on your screen. (Keep in mind I set my theme to Classic in order to debug this problem.)
The DataGrid has an Aero look, but AlternatingRowBackground isn’t being respected. Every other row ought to have a gray background.
Using the debugging techniques discussed up to now, it will be found that this is the exact same type of problem as Problem #2. An implicit DataGridRow Style inside the Aero skin is now being loaded. DataGridRow.Background uses property coercion. DataGrid.AlternatingRowBackground is a candidate value that may be returned in the coercion callback. DataGridRow.Background is another candidate. Where these values originate from will influence which value the coercion callback chooses.
By now it should be clear, but if not, it must be reiterated. Loading a theme's resources may cause adverse effects.
The short answer to this sub-problem is DataGridRow.Background must only be set in the theme. Specifically, it must not be set by a Style Setter anywhere in the application. Unfortunately, that’s now precisely what’s happening in the Aero skin. There are at least two ways to address this problem.
A blank implicit Style can be added after the Aero skin. This hides the offending Style in Aero. There are no values in the blank Style so values from the default Style end up being used. In the end, this only works because DataGridRow Styles are identical in every 4.0 theme.
Alternatively, Aero’s DataGridRow Style can be copied, the Background Setter can be removed, and the remainder of the Style can be added after the Aero skin. The solution XAML employs this technique. By expanding the Style out, the application is more likely to continue looking Aero in future scenarios. By isolating this expansion in App.xaml, DataGridResourceDictionary.xaml can be used more freely in other contexts. However, note that it may make more sense to add it to DataGridResourceDictionary.xaml, depending on how that file is used in the future. In terms of this application, either way works.
Problem #4: DataGridColumnHeader Layout
The final change is fairly superficial. If the application is run after making the recommended changes so far, the DataGridColumnHeaders will have content that is left-aligned rather than centered. This problem can be drilled into easily with Snoop or WPF Inspector. The root of the problem appears to be the DataGridColumnHeaders have HorizontalContentAlignment set to ‘Left’.
Set it to ‘Stretch’ and it works as expected.
There’s some interplay between the Layout properties and TextBlock formatting properties. Snoop and WPF Inspector allow for experimentation and make it easy to determine what works in any given situation.
Final Thoughts
To summarize, loading a theme’s resources is not the same as changing the theme at the OS level. Loading a theme’s resources may cause adverse effects. From WPF’s point of view, a large number of implicit Styles are now present in the application. These Styles may trump other Styles. The bottom line is treating a theme like an application skin may not work without refinements.
That said, I’m not completely sold on the current WPF implementation with respect to "helper properties" (e.g. DataGrid.ColumnHeaderStyle) being used via a coercion callback with precedence rules. I have to wonder why they can’t just be locally assigned to their intended targets (e.g. DataGridColumnHeader.Style) at initialization time, if the targets do not already have an explicitly assigned value. I haven't thought enough about this to know what the various problems might be, but if it's possible, it might make the "helper property" model more intuitive, more consistent with other properties, and more foolproof.
Finally, although it wasn’t the focus of this answer, it’s very important to note that loading a theme’s resources to simulate changing the theme is particularly bad because there is a substantial maintainability cost. Existing Styles in the application will not automatically be based on the Styles inside the theme’s ResourceDictionary. Each Style in the application would have to set its BasedOn property to a Type key (or be based, directly or indirectly, on another Style which does). This is extremely burdensome and error-prone. Additionally, there is a maintainability cost with respect to theme-aware custom controls. The theme resources for these custom controls would also have to be loaded to effect this simulation. And of course, after doing that, you might face Style precedence issues similar to the ones you faced here!
Anyway, there’s more than one way to skin a WPF app (no pun intended!). I hope this answer provides additional insight into your problem, and helps you and others solve similar problems.
{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://i.stack.imgur.com/ncYN5.png', '推荐 别忘想泡老子 的文章《Why can't I style a control with the Aero them》','https://www.manongdao.com/article-141995.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}