I am currently working on a WPF project, and I am at an aspect of the program where I don't know how to create the solution efficiently.
Problem:
In my program, I plan on implementing UI versions (Dark mode, Light mode, etc.). Basically just UI color preferences. However, I am unsure of the best way in which I can use the other UI features.
So far, I have set up styles for each UI preferences in the APP.XAML, based on individual properties, such as textboxes and rectangles, and put the general style within the individual pages to be shown.
The UI changes need to be kept within the same SHOWN XAML file so that events can be implemented. I believe it needs to be done by using APP.XAML (which I have already been using this). However, what would be the best way in showing the UI changes? Should I be creating a whole page style? Changing each property individually based on styles? Or is there some better way in completing the UI changes efficiently.
Thanks!
In answer to some of the questions and statements:
The standard templates (see: https://stackoverflow.com/a/45603437/563088) use Themes so that would be a logical first step to follow
It might be easier to maintain separate files with the templates and colors in resource dictionaries although templates will have to be in the Generic.xaml
Do not use events, use Commands and Bindings. If you need to use events, do not hook them up in XAML but hook them up in the OnApplyTemplate of the controls. That way templates can be swapped out and templates are no longer forced to provide specific controls/events as the OnApplyTemplate can search for a control and skip it if it isn't found.
As for switching: from experience I found it easier to define multiple color/brush/resource sets in separate files. Give these colors and brushes the same names (e.g. HighlightBrush, ButtonBorder or CheckBoxCheckGlyph). Depending on the theme you load a different resources file. the templates would simply refer to these resource names (using DynamicResource if you want to enable live switching or StaticResource for switching on restart of the window/app)
Related
I use MaterialDesign and I want to change the appearance of the popup window of a ComboBox.
I did a little research and then came across it here.
change combobox dropdown list background color wpf xaml
Miljac’s answer contains the key MaterialDesignPaper. Is there a documentation of these keys?
I am not being offered keys via IntelliSense.
There is no detailed documentation on the resource keys and where they are used. However, you can have a look at the GitHub repository Wiki. There is a page that lists all the brush names, but it does not provide any information beyond that.
If you want to know which control uses which brushes, you can check the control style list. Pick the control style that you use and it will take you to the XAML style files, where you can identify the used brushes, e.g. for ComboBox see line 548 where MaterialDesignPaper is referenced and the subsequent lines from 553 on where the popup background is bound.
IntelliSense is not reliable when it comes to resource dictionaries e.g. merged into the application resources and resources then being used in a custom view. These are limitations of IntelliSense, the resources may be perfectly available at runtime. The same applies to the designer, it may yield warnings that resources cannot be resolved, but in fact they are available at runtime.
In my UWP app, my control options are User Control and Templated Control. My understanding of a User Control is KIND OF clear at this point.
I was told that a Custom Control's style/template is only instantiated in memory once, and that this only happens at the time the control is first used. That's what I want since I know the control I am creating will be used in a ListView.
In the book, XAML Unleashed, however, the author creates his Custom Control by starting with a User Control, and then simply changing it's base class. The thing is that the control he created calls InitializeComponent(). I hear that this type of class uses more memory because it is re-instatiated for each item in the ListView.
Also, I never thought that Custom Controls used the InitializeComponent() method. I thought there was simply a call to this.DefaultStyleKey = typeof(MyClass); in the constructor. What gives? I am confused on what is what...
And last, why is the style/template of the Templated Control placed in the global Generic.xaml file, instead of its own separate file (i.e., xaml file and a code-behind file pair)? If the control is supposed to be custom and "portable", then shouldn't it be totally separate from other code? I haven't found a single article explains any of these things in detail on any level.
This is something most people get wrong so I'll try to clarify a few things for you.
Memory
The whole memory thing, it's all in the Visual Tree. When you instantiate any control, whether templated or UserControl, you will use up memory with every instance because in both cases you are creating a full copy of the visual components in the template.
The templated control will create a copy from the ControlTemplate while the UserControl parses the XAML file when InitializeComponent() is called.
Memory usage will be the same if you create 100 templated controls or 100 user controls if their content is the same.
Usage
Templated controls are best for situations where you're creating a single component, like a Button, Slider, MyStarRatingInput, etc. and you're giving the users of your control the ability to swap out the template with their own. It takes a lot more effort to do this properly than UserControls because the logic has to be template agnostic and your templates have to react properly with visual state changes.
A UserControl is best for layout or views, like forms, popups, screens, pages, etc. You will not give someone the freedom to tamper with the content of your view. You may expose a few public/dependency properties if some views are reusable in a small way, but generally they are set in stone.
Generic.xaml
I honestly don't have an answer for this. Microsoft should've allowed multiple resource dictionaries to enable cleaner partitioning of control templates. Generic.xaml is a reserved filename that referencing projects will look for as the root source of the base styles of your controls. You could reference other XAML files from Generic.xaml, but that's annoying and it bloats the root of your resource dictionary. For now, you're stuck with this method.
Recommendation
If you're sharing a control library, you would want to use templated controls as much as possible. If you're building controls, views, pages, etc for your current project and they're not meant for reuse, then use UserControls.
You can still create a UserControl in your control library if you plan on owning the template and forcing all users to accept your design.
I also recommend templated controls for items that you plan on instantiating a hundred times in a single view, like a ListView. You will see noticeable speed improvement if your template is preloaded into memory instead of parsing a XAML file on every instance.
I know how to create a simple XAML interface for a page, but I spend a lot of my time copying and pasting code since I have no idea how to create reusable XAML in a proper way, I know about styles but they don't quite fill the role. What I would prefer to do is to call them in the following way:
<CustomElement attribute1="bla" attribute2="{Binding somethingElse}"/>
Just like all the other GUI objects in the Silverlight framework.
Any help or hint would be useful.
Basically there are two options. Both solutions act like any other Silverlight control. They can be inserted at random places in pages like you would normally insert a Button or a StackPanel. The option of choice depends on the specific reuse scenario.
Create a UserControl. These define their own XAML layout and are very easy to create. Consider looking at ScottGu's tutorial.
Create a custom control. Custom controls also define their own XAML layout but through templating and styling. They are harder to create but support templating; this means other developers can decide that they will use the code behind your control, but specify a completely different layout. For more information look at Silverlight templating.
For a (much) better understanding, please look at this page comparing the features of UserControls and custom controls more in-depth.
I would like to know if there is a way to manipulate an App's UI live while running?
I am not a designer and I have many problems sometimes regarding matching colours etc.
The next problem is that anytime I would like to change e.g. the colour of a control I have to quit the App then go to VS2012, apply my changes, build and execute it again to see simple changes.
I know that I see any changes in the designer but I have to see the resulting screen to get an impression of the whole.
Is there a way to achieve this?
Add a secret keypress while Debug flag is set, that raises a form and allows you to select controls and expose a property sheet for them. Be a bit of work to get right, and a good stick of code even using reflection. Might be better off with a storyboard type app to do your designing.
Unlike styles in WPF which can be dynamically adjusted (which made this type of run-time adjustment simple), there isn't as elegant of a solution for Windows Store apps. Ideally, you'd have all of your UI and colors, etc. defined in XAML files and not settable through other means (as it becomes a longer term maintenance issue).
I'd suggest just adding enough test data and configuration so that you can see the look and feel of the pages (with colors, etc.) at design-time. Blend and Visual Studio are now quite good at showing a very reasonable near final rendering of the elements of the application. It's generally not too difficult to do anymore.
One thing I've done in the past was to make a single page/form that contained all of the styles and controls in a large scroll viewer. Then, we set it so it was configurable to the be the first thing to run. The tweak/build cycle was pretty fast, and the results were still very manageable.
I am working on a WPF app and the UI is getting a bit complex to manage. I am looking for advice on how to maintain it as it grows.
The layout looks something like this
<Grid>
<List of Objects View/>
<Objects Relationship View/>
<Object Details View />
<Multiple Objects Details View/>
<View 5 />
<View 6 />
:
:
</Grid>
Each view gets created (visibility hidden) and bound to some complex data, when the window is constructed. I want only one view visible, to the user at a time. I do this by manipulating visibility.
But the problem is the transition between views doesn't involve just fliping Visibility. It involves rebinding with currentdata, stoping background threads/timers and starting new ones (and possibly some binding again) that support the newly selected view. So what's happening is with every new view I add, I am adding a whole bunch of code to take care of all the possible transitions.
Is there some pattern I can use to deal with this kind of scenario?
Also is there some way I can avoid creating and hiding everything at app load and using visibilty as a controller?
Any help is greatly appreciated. Thanks!
May I ask how you are allowing the user to switch back and forth between the views? Is it a key combo? Mouseclick?
Not that it's answering your question per se, but my suggestion is that this sounds like a perfect scenario for a tab control. And with WPF, it doesn't necessarily have to look anything like a tab control.
If you use a TabControl, it opens up the possibility of using the SelectionChanged event coming off of the TabControl to allow you to tell background threads to stop and you can unload anything that you need to unload.
Depending on how you use the TabControl, the UI can be somewhat virtualized. What that means is that whenever a tab is unselected all of the UI for that tab is destroyed and recreated the next time it's selected. It will behave this way if you use the MVVM or PresentationModel pattern and load ViewModels as the items for your TabControl and use DataTemplates for the views. If you just put TabItems into the TabControl with controls inside of them, it will not behave this way, however.
As far as patterns are concerned, I'd definitely recommend MVVM. It may take a bit of time to catch up to it and understand it, but I'd never do WPF without it. If you need anymore resources or examples, let me know.
edit:
I reread your question and noticed that you may be in need of another type of navigation. If you've got views that are needing to make transitions to other views based on user actions and you don't want all of the views to be presented to the user so that they can select which one they want to look at (like the TabControl will do), you may want to look at WPF Navigation. Navigation is basically something that MS added in with WPF to allow browser style navigation in a WPF app. This MSDN article should be a good resource on that kind of thing.
This sounds like a problem well suited to Composite WPF (Prism). You can define your main area as a region, and use a SingleActiveRegion to show one view at a time. If you create your own region adapter, you can do all the maintenance when the active view changes.
Also, adding a new view won't involve changing the hosting view's code. This will allow you to deploy additional views in the future in separate assemblies...