Applying global styles to inherited Windows controls in control library - wpf

I'm a complete n00b to WPF but I'm working on my first application. I already realize that styles I use in the application I will likely want to use in future applications, so I'd like to use some method of applying global styles from project to project.
I've seen plenty of tutorials on creating a control library project, but they all go into creating custom controls. I don't really need custom controls (yet) per se, just the standard Windows controls with custom styles.
I'm also a little unclear on the whole ResourceDictionary thing. I've found examples on creating one for an application project, but not so much for a control library project.
What I'm looking for here is a) is a control library really what I need or am I creating more work than necessary? b) am I on the right path with a ResourceDictionary? and c) any good links to tutorials/examples that might go into what I'm trying to do rather than just a custom control creation tutorial.

You definitely want a ResourceDictionary with styles that you will be using in other apps. You can then reference it on an application, window, or even control level by including it in the application, window or control resources.
Where you put that resource dictionary isn't that important, though a custom control project is a common place to do so. It can be anywhere, in any project, and you can reference it with a URI.
Microsoft has a pretty good writeup on resources: Using Resources. Here's a decent tutorial on using dictionaries: Resource Dictionaries

You are in the right direction with ResourceDictionary. Create one for your application in a separate library move all your Styles there and refer them using Pack URI syntax. Here is a related question: ResourceDictionary in a separate assembly

Related

Where to find a free style for my WPF applicaton?

I am not happy with the default style of my application and I'd like to add a style that makes it look more professional. I downloaded some themes but the ones I found kinda ruined my window interfaces.
Any idea where to find free recent WPF styles?
There does not exist anything like this, what you are describing. You can get Windows themes, which will impact your whole OS but also your application if you have been using system colors while developing.
There is no magic formula that would know how to style which button. This is something you have to implement on your own.
What you can do is to learn more about how to properly style an application using styles from from a external . In order to make your application more appealing you can download a color pallet and follow it. The designing you will, still, have to do on your own.
There are themes pre-made available on the internet. : http://brianlagunas.com/free-metro-light-and-dark-themes-for-wpf-and-silverlight-microsoft-controls/
You need to add them to you project.

WPF: What is App.xaml's Purpose?

I've done .Net development for awhile but I'm new to the WPF technology. What is the supposed purpose of App.xaml? Also, what type of xaml code do you usually put in it? It seems like for simple applications it could be ignored and left untouched. Is this true?
App.xaml is the declarative portion of your code (usually generated by Visual Studio) extending System.Windows.Application. For example, Expression Blend can use App.xaml to share a Resource Dictionary or a design-time data set with your entire application. And, because we are using Microsoft products, whatever Expression Blend can do auto-magically, we can do by hand in Visual Studio.
Now the tangent: To me, to ask about the purpose of App.xaml is to ask about the purpose for System.Windows.Application. Feel free to accuse me of changing the original question (let the digital brutality ensue).
You can’t just open a System.Windows.Controls.Window in any Assembly you like… Chris Sells is likely telling me this in his book. I began to understand the purpose of System.Windows.Application while using MEF and MVVM Light to display WPF windows in DLLs (not EXEs). I got errors like this:
The type 'System.Windows.Markup.IComponentConnector' is defined in an assembly that is not referenced.
or
The type 'System.Windows.Markup.IQueryAmbient' is defined in an assembly that is not referenced.
The above error is simply saying that I’m trying to open a WPF Window inside of a DLL and not an EXE. Then, there’s this error:
The component 'Songhay.Wpf.WordWalkingStick.Views.ClientView' does not have a resource identified by the URI '/Songhay.Wpf.WordWalkingStick;component/views/clientview.xaml'.
This boils down to the absence of a facility that associates WPF Window XAML with the WPF “code” (an instance). This facility is associated with WPF EXEs and not WPF DLLs. Visual Studio auto-generates a WPF EXE class called App.g.cs (in your \obj\Debug folder) with this call in it: System.Windows.Application.LoadComponent(this, resourceLocater) where resourceLocater is a badly named variable containing a System.Uri pointing to the XAML like ClientView.xaml mentioned above.
I’m sure Chris Sells has a whole chapter written on how WPF depends on System.Windows.Application for its very life. It is my loss (quite literally of time) for not having read about it.
I have shown myself a little something with this unit test:
[STAThread]
[TestMethod]
public void ShouldOpenWindow()
{
Application app = new Application();
app.Run(new Window());
}
Failing to wrap a new Window in the System.Windows.Application.Run() method will throw an error from the land of COM talking about, “Why did you pull the rug from underneath me?”
For simple applications, it is true, it can be ignored. The major purpose for App.xaml is for holding resources (style, pens, brushes, etc.) that would would like to be available through out all of the windows in your application.
It is true. App.Xaml is some sort of central starting point. You CAN use it, or you CAN start your first window (it is defined in the app.xaml) manually. There are some lifetime events there centralls (like application start).
Storing resources that are used across the whole application.
Application is the root of the logical tree.
It is like Global.asax if you are coming from an ASP.NET background. You can also use it to share resources throughout your application. Comes in pretty handy for resource sharing.
App.xaml is a major part of wpf application.
It contains major four attributes
1.X:Class->used to connect you xaml and code-behind file(xaml.cs).
2.xmlns->To resolve wpf elements like canvas,stack panel(default one).
3.xmlns:x->To resolve XAML language definition.
4. StartupUri->To give start window when application is launching.
++++++++
App.xaml is the declarative starting point of your application. Visual
Studio will automatically create it for you when you start a new WPF
application, including a Code-behind file called App.xaml.cs. They
work much like for a Window, where the two files are partial classes,
working together to allow you to work in both markup (XAML) and
Code-behind.
App.xaml.cs extends the Application class, which is a central class in
a WPF Windows application. .NET will go to this class for starting
instructions and then start the desired Window or Page from there.
This is also the place to subscribe to important application events,
like application start, unhandled exceptions and so on.
One of the most commonly used features of the App.xaml file is to
define global resources that may be used and accessed from all over an
application, for instance global styles.
+++++++++
Source : http://www.wpf-tutorial.com/wpf-application/working-with-app-xaml/
Here is an updated answer in case people are still looking.
There is this excellent article on WPF, and the link specifically puts you at the App.Xaml point to begin teaching you the things you can do with it.
WPF is easy for the first very simple app or two. However, due to the increased flexibility of the framework, you need these types of tutorials to help you understand what can be done from where (in the various application files).
https://www.wpf-tutorial.com/wpf-application/working-with-app-xaml/
Good luck.

Resource Dictionaries in a Silverlight Assembly?

I've just begun dabbling in putting together a set of controls as assemblies and I'm working on default styling. What I currently have is a UserControl in a project (thanks Reed!) and I'm able to bring that into another project via reference. I plan to add more controls over time to build something of an SDK.
I currently have some hooks that look for resources in the hosting application which either apply the resources to their respective properties, or style out the control via hard coded defaults.
Is it possible to set up resource dictionaries within the project containing the UserControls so they can use those references as the default, instead of hard coding? If so, how do I target them?
(I have a ResourceDictionary set up within the same project as the controls: Resources>Dictionaries>Colors.xaml)
Thanks in advance!
E
You should really look at creating custom templated controls in library rather than derivatives of UserControls. This will allow projects that reference your library to specify an alternative default style for you controls in the same way as we can for the controls in Microsofts own SDK.
The Creating a New Control by Creating a ControlTemplate topic on MSDN is good starter.
I think this is a better explanation, but i'm trying on a desktop application and i got the same problem.
XamlParseException: Failed to create a 'System.Type' from the text 'local:CustomerEntity'
If I'm undestanding correctly you want to create the file "generic.xaml" in the folder "Themes". However, I don't believe automatic styling works with UserControl only with Control. Generally if you trying to make a control that can be stylized and retemplated you want to inherit from Control and not UserControl.

How do I build a Style Library for use in Silverlight Class Libraries?

I have a Silverlight application that is built from a set of Silverlight class libraries. I would like to create a common Silverlight library that contains a set of resources used to define the styles used for all the Silverlight UI libraries. This would be simlar to the <Styles>'s defined in the node within App.xaml file.
Is this possible? And if so, how would I implement?
While this is possible using WPF (via Dynamic Resources, see this video and fast forward to 12:00), I don't think this is possible yet in Silverlight. The closest thing you have to this is the themes in the Silverlight toolkit. There is a comment on that page by the team stating that you can't change themes (or resource styles) at runtime in Silverlight 2:
unruledboy, We do not support changing themes at run-time as this is not an ability supported by the Silverlight framework.
So I think themes is the closest thing available right now.

Is there any way to share resources in a Silverlight library project?

In a silverlight application you have App.xaml, but in a Silverlight library you don't. I tried using generic.xaml but I think this serves the specific purpose of applying styles to all controls based on their type. In case, I just want a place to put things like paths or objects that I will reuse throughout the library.
Take a look at the Silverlight Toolkit's SharedResources.cs file, it's a little hacky but may help with your scenario.
It isn't the same as sharing XAML resources, but it may help you get access to images and other embedded content types.

Resources