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.
Related
I am working in WPF and WinForms for both Windows XP and Windows 7/10 users (.NET 4.0 due to XP).
Some WPF Windows are used as dialogs for older WinForms applications without a WPF Application class/App.xaml file.
This in itself isn't a problem but I find I'm having to declare styles in resource dictionaries in user controls/windows in the WinForms/WPF situations which isn't normally necessary in plain WPF applications due to App.xaml.
My question is whether WPF detects that the same resource is being loaded twice (in a pure WPF application e.g. UserControl and App.xaml) and copes with/manages this without interference from me or do I have to try to ensure I only declare resource dictionaries once?
Many thanks.
The answer is no.
If you load a resource dictionary as a resource for a usercontrol then each instance of the usercontrol means another instance of any resources it uses in memory.
If that is going to be a problem then you need to do something.
You might just be able to instantiate an application object and use that to stash your resources in. Application.Current.Resources is after all just referencing the current application. Depends on exactly how your app works.
If you try to load the same resource dictionary twice, the application will throw a runtime error.
But, if you are only defining the styles already present in the resource dictionary, in the user control also, i.e, basically two styles with the same name one in the resource dictionary and the other in the user control, then no error is thrown. The style in the user control will have a higher priority.
I'm trying to work out the best way to couple my Views and ViewModels in MVVM and I've settled on the ViewModel-first approach using typed DataTemplates, as described in this article and in this answer. I'm using Prism and have multiple modules which have their own projects/class libraries.
My question is: Where should my DataTemplates live in my solution?
Should I put the DataTemplates in a Resource Dictionary which lives in the same project that has the types/ViewModels it renders?
Should I put the DataTemplates in a Resource Dictionary which lives in the project which has the application's MainWindow (i.e. Shell.xaml)?
Should these Resource Dictionaries then be added to App.Current.MainWindow.Resources.MergedDictionaries?
I hope this is enough information to describe what I'm trying to do.
Update: see comments of selected answer.
I'm sure that the best way here is to use Themes\Generic.xaml resources file. This is file (it should be exactly in folder Themes and has name exactly Generic.xaml) used by WPF/Silverlight themes engine and contains resources shared through whole application. You can also create separate file in folder Themes with name like Generic.DataTemplates.xaml and add link to it from Generic.xaml. Google knows a lot about generic.xaml or you can see more details in my answer here: WPF Prism - Where to put Resources?
Updated to explain more clear.
I will say if your DataTemplate is generic:
i.e You have a UserControl that binds to a ViewModel, and that ViewModel has BaseViewModel, which expose some sort of properties. Your DataTemplate is displaying those properties. So you can use this DataTemplate on every ViewModel that Implement the BaseViewModel.
Is better to put it in App.xaml, so you will able to pull it out with the Key and apply on different place in your project.
But if your DataTemplate is very specific,
i.e There is a UserControl that only binds on the specified property in that ViewModel and you know no other control will binds to that ViewModel, you will want to put into the same Xaml file's Resources or where you define your UserControl.
According to Microsofts App Studio the DataTemplates should live in a DataTemplates Subdirectory under the Views Directory. A Universal app has this directory for both the Windows UI as for the Windows Phone UI so its not in the Shared project because they are not the Same. Don't use the Converge PRISM architecture. Its completely wrong designed! That was not written with a Windows and a Windows Phone architecture in mind but like they call it Converged. It should have been completely redesigned like it works in Microsofts App Studio. Don't look for Dependency Injection its not in it and not needed. Most use Dependency Injection for stub or fake interfaces. The DataContext for design data works now so good with json data that a Dependency Injection component would be overkill.
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
In WPF applications all the views are inherited from System.Windows.Window and have an associated xaml and codebehind file. That seems logical.
However I'm confused that why does the App file, inherited from System.Windows.Application, have a xaml file? Although it is an application and not a view (It is not visible)? I know that this file is usually used to define application resources, etc, and xaml provides an efficient way of defining them. But that can also be done programatically. Then what benefit did the designers of wpf achieve by having both the xaml and code behind files for "App"? Wouldn't one of them have been enough?
However I'm confused that why does the App file, inherited from System.Windows.Application, have a xaml file? Although it is an application and not a view (It is not visible)?
Remember that XAML is not a UI language, but a general declarative language. While it's true that it's mostly used to represent UI for WPF or SilverLigth, it's also used to declare graph of objects in other non-UI technology.
The first example that comes into my mind is the Workflow (the XOML is a derivate of the XAML), SharePoint also use XAML in some hidden parts, and I've seen in a customer project with use XAML as a meta-language for generating web-apps (and yes, it actually outputs HTML).
Then, to answer to your question, the application have both files (and it is not actually a requirement) because you can :
declare some objects (in the xaml)
override the behavior of the application (by overriding appropriate methods)
Designers can specify resources for entire application without entering any code and use it in any Window. Its something like a root for all windows. For example, if you use one style for every TextBox (or any other control) in every window, you can specify it in App.xaml and bind anywhere without duplicating.
What is the best practice for creating re-usable control templates.
For example. I want to start with the standard checkbox and modify its template for re-use accross multiple future projects.
I understand how to modify the template in Blend, but it always wants to save the template to App.xaml of the current project or to the parent control where I first placed the checkbox.
Ideally I would like some soft of ControlLibrary that contains all my custom controls AND custom templates (modified templates of existing controls)
-Jeff
Implicit Style Manager might be helpful.
The Silverlight controls team and others have been blogging a bit recently about ISM which allows alternative style sets to be applied across the board to standard controls. Try Jesse Liberty's blog or Mehdi Slaoui Andaloussi's blog
HTH
I don't think you can have a ControlTemplate as a separate entity, without it being attached to a Control. For your control library you can create custom controls that have the appropriate custom templates and reuse the controls.