I've spent hours working on an application design in WPF and created a whole bunch of different styles along the way. But I noticed that I actually had just edited the styles in the SimpleStyles.xaml file and not a custom dictionary.
So, I started right clicking all controls I could find and selected "edit a copy" and created a copy in a custom resource dictionary. But then I found that alot of the controls are based on several styles. SimpleScrollViewer e.g contains both the thumb and probably more. This created a huge mess in the overall structure of styles in the entire project.
And thus, my question is as follows;
What should I think about when doing this project from scratch again?
Is it best to edit a copy of the SimpleStyles controls? Is there a tool of some sort to manage stuff like this?
Expression Blend will add a resource dictionary for the Simple Styles the first time you use a SimpleStyled control. For real world projects it is best practice to separate resource dictionaries by resource type and then functional area.
For example you will have horizontal resource dictionaries that fall into the following categories:
Brushes
Control Styles
Converters / Selectors
Since these are horizontal their filenames are pretty self-explanatory (e.g. Brushes.xaml, ControlStyles.xaml, Converters.xaml, etc.)
If you are using Silverlight you should probably think about using Themes. In which case you would create Brushes.xaml and ControlStyles.xaml for each [themeName]\generic.xaml you create.
Then you should create resource dictionaries for functional areas that will house the following things:
Item Templates for various ItemsControls used.
Content Templates for various ContentControls used.
One off Control Styles
Each functional area would have a resource dictionary that had the above items (e.g. CustomerManagementStyles.xaml, Orderingstyles.xaml, etc.)
Related
I am writing a WPF application using "Prism", and some purchased Grid theme is applied "Xceed Theme." I am designing a huge change required by our customer to give them the option of modifying some properties (like the background of selected row, for example) and this functionality to be available per screen "Module."
So my questions are:
After adding my xceed grid theme source to my App.xaml merged dictionaries, how can I override some of its styles (that I know the keys of) in another xaml file away from app.xaml (possibly by adding BasedOn to the style tag)?
Is it possible to create a custom resource dictionary for each module and add it to the app.xaml merged dictionaries while loading?
You could add the style changes in the main window/control's resources within each module. Then the differences would apply to each module separately.
In my case, I have userd Dynamic Resources. The main project loads the main style. somthing like this :
<FontFamily x:Key="ApplicationFontFamily">Tahoma</FontFamily>
and in my module i have changed it programmatically :
Application.Current.Resources["ApplicationFontFamily"] = new FontFamily("Arial");
it worked for me ;)
I have started using xaml based icons in my WPF app, but am struggling to find a simple way to store and share them. The icons are DrawingBrushes.
Do I?
A) Store each icon in its own xaml file wrapped in a resource dictionary. This means that I either have to pull in each icon resource every time I want to paint one, or create a standard "icons" dictionary that pulls every xaml file. This seems a pain to have to maintain, and I still have to pull in the icons resource dictionary every time I want to use an icon.
If I did go for this, how do people normally display the icon? Just a Canvas with the brush as the background?
B) Store each icon in its own xaml file as a UserControl. This makes displaying an icon dead easy - just plonk the approprate control in, and its arguably simpler to declare the XML icons namespace at the top of your XAML rather than merging a resource dictionary.
C) Store all icons in one XAML file wrapped in a resource dictionary. One dictionary to merge but without the maintenance of pulling in individual files into that dictionary. Potentially awkward to edit icons though.
D) ....?
How are other people managing their icons?
it seems there are a number of approaches on how to implement multiple languages in a WPF application. But I would like some more information about what method I should be using with the following requirements:
It's a PRISM application, so a number of independent modules (assemblies) working together. I would like that each assembly has its own translations of UI elements.
I need a simple approach, no tools needed to generate stuff
Should still be able to use blend to design the UI
Optionally be able to switch language without restarting the application (not a dealbreaker)
Can someone advice me on how to achieve this?
Thanks!
A common approach is to bind the text property of your textblocks / labels etc.. to some property on a statically defined localization resource:
<Label Content="{Binding Source={x:Static loc:LanguageContext.Instance},
Path=Dictionary, Mode=OneWay,
Converter={StaticResource languageConverter},
ConverterParameter=TextId}" />
i.e. LanguageContext.Instance exposes a dictionary via a property Dictionary, the Converter uses the given ConverterParameter to look up the text identified via TextId.
This is a cumbersome approach, and will not fulfil all your requirements.
A better method is to defined your own markup extension to perform this sort of logic. There are a couple of solutions I have seen on the web, this high rated codeproject article:
http://www.codeproject.com/KB/WPF/realtime_multilingual.aspx
And a similar solution here that provides Blend, on-the-fly language changes, so is probably a good choice for you:
http://blogs.microsoft.co.il/blogs/tomershamam/archive/2007/10/30/wpf-localization-on-the-fly-language-selection.aspx
With the above example you define an attached property which identifies the key of the translated item, and use the Translate markup extension to identify the properties which are translated.
NOTE: it is not just text which is being translated here, often you have to change colors / graphics etc ...
Meanwhile I found an open source project that works really well: http://wpflocalizeextension.codeplex.com. It's just adding a reference to the dll, adding the resources with translations, and using it in XAML. It worked in 5 minutes. I can add multiple resources to individual modules; and it works fine in visual studio designer and blend. And, locale can be changed on the fly. Meets my requirements :)
I have a WPF application made up of around seven user controls, each with a variety of different controls on each (textbox, combobox, radio button etc).
Across the entire app I have applied a set of control styles take from the WPF Themes on CodePlex, however I have noticed a bit of a slowdown on the app since applying these styles. The ResourceDictionary containing all my styles weighs in at nearly 300kb in code size.
Would there be a benefit to gain by splitting the styles in to multiple Resource Dictionaries and only merging the styles that each usercontrol requires rather than the all the control styles even if they are not being used.
How does WPF load styles in to memory? When required or is the whole ResourceDictionary loaded in to memory at startup?
When an object is created from XAML (or BAML), the XamlReader deserializes all of the XAML's contents. Every XAML element it finds creates an instance of an object - so the Style elements under the UserControl.Resources element generate Style objects that get added to the user control's resource dictionary at the time the object is deserialized. (It's actually a little more complicated than this, since there are apparently parts of XAML deserialization that are asynchronous, but it's close enough for the purposes of this discussion.)
It's important to understand that Resources is not a static property. Every instance of a user control has its own resource dictionary. If you put 300 styles in the user control's XAML, and you create 100 user controls, you'll be creating 30,000 Style objects. This is true whether you're using merged dictionaries or not.
If your resource dictionary is as huge as you say, by far the best thing to do is to put it into the application's Resources property. That way you only pay the price of deserializing each object once.
I wanted to know which one amongst Style and UserControl would be better to use in WPF?
For example:
I have created an image button in two different ways.
One uses Style and ContentTemplate property is set.
It uses one other class with dependency properties.
The other way is I have created a UserControl which has a button and its content property is set.
The file UserControl.xaml.cs also contains the dependency properties.
For Code details see the answers of this question:
Custom button template in WPF
Which one would be better to use? In which scenario should one go for Style or UserControl or any CustomControl?
Styles are limited to setting default properties on XAML elements. For example, when I set the BorderBrush , I can specify the brush but not the width of the border. For complete freedom of a control’s appearance, use templates. To do this, create a style and specify the Template property.
Styles and templates still only allow you to change the appearance of a control. To add behavior and other features, you’ll need to create a custom control.
For example,
To create a button like a play button use styles and templates, but to create a a play button which will change its appearance after pausing it use UserControl.
For this type of thing I would go with Style, even though I'm not really adept with graphical tools. I tend to produce a basic, boring style that I can get started with and then prettify it once the application functionality has been verified.
The nicest thing about WPF is being able to distance much of the graphical look, feel and behaviour away from the code.
This allows you to change the style of your application without revisiting the code and indeed means that you can change styles on the fly at runtime.
There is an awkward line to tread with regards to how much behaviour is placed within the XAML and how much is placed within the code. A rough guide would be to decide on what behaviour must always be present within the UI and place that in the code, everything else place within the XAML.
Think of the code as being an abstract class with defined interfaces and the XAML Styles as being classes based on that class and you'll get an idea of what I mean.
Conversely, I know that people who are far more adept at the GUI work prefer to put more functionality in the XAML and others who prefer the code side, because they find the GUI work slow or difficult.
When thought of that way you'll see that there's never really a right or wrong answer, just better solutions that suit your skills.