StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<blockquote> <p>I read on MSDN that ThemeInfo must be declared with 2 parameters responsible for control theme specific location and generic specific location, though I have no idea what is "theme" and what "generic". How can I understand those two better?</p> </blockquote> <p>Basically the WPF framework will look for a xaml resource whose name matches the OS theme name. So if you're running on XP with the blue theme that will be "luna.normal.xaml". If it does not find one with that exact name, it will look for the "generic.xaml". In actuality I think they look for the "classic.xaml" first if they don't find one that matches the OS specific one and then they look for generic.xaml. You can think of the generic.xaml as the default resources.</p> <p>The ThemeInfo attribute simply tells WPF <em>where</em> those resources are defined. There are 3 options:</p> <ul> <li><strong>None</strong> - You aren't providing either the "theme" or "generic" resources. This is really an optimization so the WPF framework doesn't bother looking for them. You wouldn't typically use this for the <strong>GenericDictionaryLocation</strong> but you might use this for the <strong>ThemeDictionaryLocation</strong> in case you weren't going to define OS theme specific resources (i.e. you didn't want your control to look different under different OS themes). Typically control vendors will define a resource dictionary for each possible OS theme so that the controls look consistent with the other controls and windows running in that operating system.</li> <li><strong>ExternalAssembly</strong> - This means that you are defining a separate assembly for the resources. So if you look at the WPF framework you will see that they use this for the <strong>PresentationFramework</strong> assembly for the <strong>ThemeDictionaryLocation</strong>. Then they defined a separate assembly for each OS theme they want to support (e.g. PresentationFramework.Aero.dll, PresentationFramework.Luna.dll, etc.). The name of the assembly it will search for is the name of the defining assembly plus the name of the theme.</li> <li><strong>SourceAssembly</strong> - This means that the resources are defined within the assembly itself. So in that assembly you would have a "themes" folder which contains the resource dictionaries.</li> </ul> <p><a href="http://msdn.microsoft.com/en-us/library/ms745025.aspx" rel="noreferrer">This article on MSDN</a> about control authoring really isn't that bad about providing information about this.</p> <blockquote> <p>Also can somebody please tell me how to just by using ThemeInfo tell my "MyCustomControls.dll" to use dictionary resources defined in "MyAnotherCustomControls.dll"? Is that even possible to do just by ThemeInfo or do I have to deal with MergedDirectories in "MyCustomControls.dll"? I would like the WPF system take care of locating resources so that I can use style keys from "MyAnotherCustomControls.dll"without the need to add merged directory in "MyCustomControls.dll".</p> </blockquote> <p>You can't use ThemeInfo to tell WPF that it should look for your resources in some arbitrary assembly. That being said if you don't set or override the <strong>DefaultStyleKey</strong>, as is typically done when defining a custom control, then it should continue to use the resources for the base class that did have its DefaultStyleKey set/overridden for the default resources.</p> <p>It should be noted however that <em>local</em> Style resolution (i.e. when the Style property of your control is not set and WPF looks from the place at which the element is sited and walks up the visual/logical tree looking for a Style that might implicitly affect that element) will <strong>always</strong> look for Style whose Key matches the exact type of the class. So if have a Style whose TargetType (and therefore the default Key when that is placed in a ResourceDictionary) is TextBox defined in the Resources of your Window, it will affect all TextBox instances within that Window (unless they have a Style closer in the visual tree - i.e. defined in the resources of an element between itself some ancestor - or its Style property is set). However, if you have a class that derives from TextBox (e.g class MyTextBox : TextBox) then it will not pick up/use that Style. Instead it will be looking for a Style whose TargetType/Key is typeof(MyTextBox). One way to hack around that would be to set the Style property to a DynamicResource to the base type. e.g.</p> <pre><code>public MyTextBox() { this.SetResourceReference(StyleProperty, typeof(TextBox)); } </code></pre> <p>Basically this sets a local value on the control's Style property that is doing a dynamic resource lookup for a Style whose Key (and therefore TargetType for Styles where the x:Key is not set) is the specified type (TextBox in this case).</p> <p>As you noted the alternative is to define the xaml files locally in your assembly for each theme that the base class' assembly defines and then add a ResourceDictionary to its MergedDictionaries that uses the <a href="http://msdn.microsoft.com/en-us/library/aa970069.aspx" rel="noreferrer">pack uri notation</a> to reference the resources in the base class's assembly. If you are setting the DefaultStyleKey then you will likely need to define a Style whose TargetType is your class' type in each of those ResourceDictionaries and then set the BasedOn to a StaticResource where the resource key is the type of the base class. It sounds though like you shouldn't need to do this.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload