I think I'm asking for a lecture on the proper application of WPF here but I'm going to take my chances since I'm at my wit's end. I think this is probably largely a result of my lethargy in fully embracing WPF templates and styles so I'm happy to listen to any such lectures.
I'm writing a sort of audio editor / event orchestrator. I've got a track editor that I'm fairly happy with. However, I built it largely out of custom controls (I know, this is probably a WPF sin). In keeping with that theme, I want to make a standard header for the tracks but I want the individual track "types" to be able to define what goes in that header. I thought a control that defines a sort of "grip" on the edge and then allowed the implementer to "fill in" the substance would work well. However, I have no idea how to do this in WPF without using styles and even if I end up using styles, I would like to understand this.
This probably comes down to wanting a sort of exemplar implementation of a simple ContentControl control (e.g. a button) and not being able to find one (other than AvalonDock, which ultimately uses - correctly i'm sure - templates for this). In my head, the xaml looks something like this:
<ContentControl x:Class="TestArea.CustomContentControl2"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
mc:Ignorable="d"
d:DesignHeight="300" d:DesignWidth="300">
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="100"/>
<ColumnDefinition Width="*"/>
</Grid.ColumnDefinitions>
<TextBlock Text="Hello"/>
<ContentPresenter Grid.Column="1"/>
</Grid>
But of course, that doesn't work. I'm fairly sure I could pull the same thing off by playing tricks with overloads behind the scenes, but it would be nice if I could do something like this. Do I really have to put all my terrible, procedural ways behind me and use these styles you speak of? If so, can someone at least tell me what that button looks like down in the framework?
Here is a complete example of deriving from ContentControl to accomplish what you want: Creating Customized UserControls (Deriving from ContentControl) in WPF 4
Pete's ContentPresenter is doing the same thing as it does in your example.
Using styles allows you to seperate functionality of a control with representation of a control; such as the Button.
Think as a control at the start as nothing more then functionality. A simple class containing predefined events, properties, etc... Once that control takes on the job of becoming part of a visual tree it now needs a visual identity. It didn't need one previously; however now it does. Defining a default style allows that control to now have a visual representation which it did not need prior as it was not living within the visual tree.
Ignoring styles would be like ignoring CSS when making use of HTML.
Related
When a named XAML element is used in a WPF application, it can be accessed from anywhere. For example:
<Grid>
<Grid>
<TreeViewItem Name="itemScreen" />
The element itemScreen will be directly accessible in MainWindow(), although it is several levels deep in the XAML hierarchy.
How does WPF enable this to work in C#?
There's a mechanism called NameScope.
https://learn.microsoft.com/en-us/dotnet/framework/wpf/advanced/wpf-xaml-namescopes
Simple markup you put in a window which has no templating or styling will all have the one namescope.
If you dig through that link it will explain about styles and templates in more detail. Essentially, they have their own namescope.
This is probably as far as you want to go with an explanation at this stage but there are a couple of oddities like when you "inherit" a style using basedon.
I wouldn't worry about them just yet but throw it to the back of your mind for later.
ps
That control is a private member of your window and the name doesn't have to be unique across the entire application.
Im building an application where I want to head for a design, that could remind of a dockpanel.
What I want, is having buttons in the left side (or left panel) representing different areas of the application (e.g "Milk", "Bread") and then have different "views" in the middle-panel.
What I already have tried, is making an application with a "Frontpage", and buttons changing the whole window/usercontrol - this however will not give me static areas/panels.
I do not want to use a tabcontrol with the tabtitemstrip being vertical - however it is kinda the same functionality im looking to have.
Any ideas?
Below is a picture with the wished design, to kinda give an idea of my thoughts.. Any help appreciated :)
http://s57.photobucket.com/user/RolleKn/media/wpfdesign_zps3737b014.jpg.html
If you use WPF, use ContainerControl or ContentPresenter for that.
In general, "switching Visibility On/Off" is not a good way to go. It forces the UI to create all objects, even those invisible ones, and to handle their data and events, etc.
And you need to switch it all manually.
WPF provides you with many mechanisms that can save you this. Some are smarter than others, some not.
One of the most basic mechanism in WPF is the Control and its Template property. You can replace whole your Grid+Contents+SwitchingVisibility idea with a single Control and switching its Template:
<Window.Resources>
<ControlTemplate x:Key="panel1"> ..carrots.. </ControlTemplate>
<ControlTemplate x:Key="panel2"> ..cucubers.. </ControlTemplate>
<ControlTemplate x:Key="panel3"> ..donkey.. </ControlTemplate>
...
</Window.Resources>
<Grid x:Name="LayoutRoot">
<Control x:Name="foo" />
</Grid>
Now, if you get the foo and set its .Template and set it to panel1, then the "carrots" will show up. if you set it to panel3, donkeys. And so on.
It's very powerful, but it will not be really handy due to some other things I won't cover. There are books and tutorials that explain Templates in depth. Also, this mechanism is really not designed for such task. It's the most basic one, and a good thing to know if you want to work in WPF, but there are more suitable ones here.
Second next powerful and still basic mechanism is ContentControl/ContentPresenter. They work almost in the same way (actually CC uses CP internally), so I'll skip it.
ContentControl is a smart control that knows how to automatically select a correct Template with respect to the data you are tryng to present.
So:
<Window.Resources>
<DataTemplate DataType="CarrotData"> ..carrots.. </..>
<DataTemplate DataType="CucumberData"> ..cucubers.. </..>
<DataTemplate DataType="DonkeyData"> ..donkey.. </..>
...
</Window.Resources>
<Grid x:Name="LayoutRoot">
<ContentControl x:Name="foo" Content="{Binding ..}" />
</Grid>
Note the change from 'ControlTemplate' to 'DataTemplate'.
Now, with this setting, you don't even need to switch templates manually. You just get the "foo" and set its Content to either:
a CarrotData object, that contains the carrot-related data
a CucumberData object, that contains the cucumber-related data
a DonkeyData object, that contains the donkey-related data
Once you set the data to be shown (i.e. foo.Content = carrots[5]), the ContentControl will pick the relevant template to be shown.
You can bind the Content property to just about anything. If you have some dataclass that contains carrots/donkeys and has a property CurrentThing, you can bind to it and ContentControll will switch the views automatically along with the changes to CurrentThing.
That's basics. There's much more to it, in almost any point I tried to briefly cover. For now, leave ControlTemplates. Read about DataTemplates and Bindings. Read about ContentPresenter (shows 1 template for 1 item) and ItemsControl (shows N items+templates). Then, read a little on MVVM pattern.
You will quickly see that "having everything in one Grid" and "switching Visibility" is an odd way to do it.
However, I wouldn't be fair if I didn't mention that everything has a cost included. Extensive use of templates and bindings makes your app a bit slower compared to what you could get when you do everything manually. But usually, doing it manually is just not really worth it.
In WPF, I can add whatever UI into ListBoxItems by providing the ListBox with an ItemTemplate:
<ListBox ItemsSource="{Binding}">
<ListBox.ItemTemplate>
<DataTemplate>
<Border BorderThickness="1" BorderBrush="Gray" CornerRadius="8" Padding="4,0,4,0">
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="50"/>
<ColumnDefinition/>
</Grid.ColumnDefinitions>
<Grid.RowDefinitions>
<RowDefinition/>
<RowDefinition/>
<RowDefinition/>
</Grid.RowDefinitions>
<CheckBox Grid.Column="1" Content="Is Active Customer" IsChecked="{Binding IsActive}"/>
<Label Content="Id:" Grid.Row="1" HorizontalAlignment="Right"/>
<Label Content="Name:" Grid.Row="2" HorizontalAlignment="Right"/>
<TextBox Text="{Binding Id}" Grid.Row="1" Grid.Column="1"/>
<TextBox Text="{Binding Name}" Grid.Row="2" Grid.Column="1"/>
</Grid>
</Border>
</DataTemplate>
</ListBox.ItemTemplate>
</ListBox>
Results in:
Is there any way to achieve the same in Windows Forms?
Edit:
1 - Is there any way to achieve the same in Windows Forms, all while maintaining separation of concerns between the View and the Application Logic in such a way that if I later wanted to completely redefine the View, I wouldn't have to refactor the entire application?
2 - Does winforms support databinding in such a way that each of my ListBoxItems can be bound to a complex Entity, eventually including an intermediate type conversion from Model data to UI data and back, in such a way that I don't have to write tons of boilerplate code to populate the view and then pass the UI values back into the Model in order to save?
3 - What if I wanted to introduce Animations in such a way that the currently SelectedItem would animatedly expand itself into some kind of "Row Details" mode, where you can see a lot of additional information?
4 - Does winforms support UI Virtualization in such a way that if I have, say 1 million items it doesn't take a lifetime to load the UI, and only render what's visible on screen?
5 - Say I wanted to introduce complex graphics to the equation. Is winforms rendering hardware-accelerated?
6 - How do I make all this Resolution Independent in such a way that the ListBox and all its contents stretch to the available window size in order to leverage larger screens while maintaining compatibility with smaller ones?
7 - It's been suggested to use the ListView control instead of a regular ListBox, does the ListView provide the ability to add ANY UI into it? can I add Videos for example for each item? or a complex Master/Detail template with Save and edit Buttons?
8 - Does winforms provide a consistent and adequate Document Model that enables the creation of high-fidelity WYSIWYG documents and other types of rich content?
To answer the overarching question - how to do this in WinForms - I'd suggest the following:
Use a WPF ListBox in your WinForms application, wrapped in an ElementHost. This has its own issues, but I think it's the cleanest way to get the desired effect.
if that doesn't fit the bill, then
Use a third party control suite that has components which support this (Infragistics and DevExpress both do).
Spin your own derived ListBox control that overrides paint, etc to render the desired content.
To your individual questions:
Is there any way to achieve the same in Windows Forms, all while maintaining separation of concerns between the View and the Application Logic in such a way that if I later wanted to completely redefine the View, I wouldn't have to refactor the entire application?
In the past, I've used the MVP (model-view-presenter) paradigm with Windows Forms. It works for separating the view from the business logic, albeit not as cleanly as an MVVM approach with WPF. The best advice I can give is: don't put business logic in event handlers.
Does winforms support databinding in such a way that each of my ListBoxItems can be bound to a complex Entity, eventually including an intermediate type conversion from Model data to UI data and back, in such a way that I don't have to write tons of boilerplate code to populate the view and then pass the UI values back into the Model in order to save?
No. Windows Forms databinding does not support complex data binding. You could implement something yourself via ICustomTypeDescriptor or IBindingSource that can take complex paths and evaluate them for binding purposes...but nothing exists out of the box for this.
What if I wanted to introduce Animations in such a way that the currently SelectedItem would animatedly expand itself into some kind of "Row Details" mode, where you can see a lot of additional information?
You'd have to roll your own Windows Forms ListBox and ListBoxItems and override the paint operations.
Does winforms support UI Virtualization in such a way that if I have, say 1 million items it doesn't take a lifetime to load the UI, and only render what's visible on screen?
Not out of the box, but some third party control suites have components that support types of virtualization...but not at all in the same way WPF does.
Say I wanted to introduce complex graphics to the equation. Is winforms rendering hardware-accelerated?
Windows Forms is based on GDI+. GDI+ is not hardware accelerated: Windows Forms very slow under Windows7?
How do I make all this Resolution Independent in such a way that the ListBox and all its contents stretch to the available window size in order to leverage larger screens while maintaining compatibility with smaller ones?
You can use Docking and Anchoring in Windows Forms to accomplish this. Or you can add custom event handlers to perform appropriate layout adjustments based on resolution and Window size.
It's been suggested to use the ListView control instead of a regular ListBox, does the ListView provide the ability to add ANY UI into it? can I add Videos for example for each item? or a complex Master/Detail template with Save and edit Buttons?
This is simplifying...but a ListView is simply a ListBox that supports multiple view types. It is also more limited in terms of databinding. http://blog.gfader.com/2008/09/winforms-listbox-vs-listview.html.
Does winforms provide a consistent and adequate [Document Model][2] that enables the creation of high-fidelity WYSIWYG documents and other types of rich content?
No. Not at all. Not even a little bit.
In short, if it's an acceptable solution, I'd wrap your WPF ListView in an ElementHost and call it a day.
We did this by using UserControls in a scrollable panel.
Prepared a user control which has all the editing control on it.
Add them to a scrollable panel with dosk property is set to Top.
Implemented the item selection behaviour by watching the focus and click events on the added user control items.
Soon to be a professional .NET developer (I hope) I start to dig into Windows Presentation Foundation (WPF). Looking into several video tutorials, I find design of GUI a daunting task. Having to specify every color, on every element, in every situation, to every platform seems a bit too much. How can you make this process simpler, and more generic when it comes to design? Is there any templates to start from, or is one expected to specify a couple of hundred rows of XAML before the design is looking appealing?
Considering the code-block below...
<Style TargetType="{x:Type Button}">
<Setter Property="Background" Value="LightGreen" />
<Setter Property="Foreground" Value="DarkGreen" />
</Style>
... where properties for hover and pushed-button style is left out which need additional rows of XAML to do what the developer wants.
Might there be a simple XAML-editor around to increase productivity? If there isn't, its just to dig dip into XAML and start building styles too keep for later projects.
Designing your own theme is great but it requires a lot of expertise and time. From my point of view its not a great idea to invest in designing your own theme, provided you already have so many themes availabe online. You can take one which suits you and modify it as per your needs.
I genrally refer these links for themes -
WPF Themes -
http://wpfthemes.codeplex.com/
http://wpf.codeplex.com/wikipage?title=WPF%20Themes&ProjectName=wpf
WPF Theme Selector
http://wpfthemeselector.codeplex.com/
Wpf Project With 21 Theme
https://marketplace.visualstudio.com/items?itemName=AliAlikhani.SahaWpfTheme2012
In case you need more options you can buy one here -
http://www.xamltemplates.net/wpf-themes/
There is no requirement to create a Style. You can just use the default style. Consider this simple messagebox style window:
<Window x:Class="MyProject.Test"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Test" Height="217" Width="298">
<StackPanel Orientation="Vertical">
<Label>Here is the Message.</Label>
<StackPanel Orientation="Horizontal">
<Button>OK</Button>
<Button>Cancel</Button>
</StackPanel>
</StackPanel>
</Window>
If you really need to re-style controls, I would pick and choose which ones to do. Otherwise, yes I think creating a custom style is a pretty big task.
Creating a custom style is a very large task, however, should you decide this is neccesary (it's not required). You can use Expression Blend to speed up the process.
Reuxables have a couple of free themes you can try. We've just bought one of their non-free ones and it's dead easy, you just throw in a reference in your app.xaml and it transforms your app. Easy to tailor, too.
Is it possible to wrap the old System.Windows.Forms controls in System.Windows.UIElement? I know that the Browser Control is somehow wrapped and the base is from System.Windows.Forms.
If this is possible, would the implementation cause any consequences?
You can host a Windows forms control in your WPF forms. Just wrap it inside a WindowsFormsHost element. This shows how to host a windows forms masked test box in side a WPF window.
<Window x:Class="Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:wf="clr-namespace:System.Windows.Forms;assembly=System.Windows.Forms"
Title="HostingWfInWpf"
>
<Grid>
<WindowsFormsHost>
<wf:MaskedTextBox x:Name="mtbDate" Mask="00/00/0000"/>
</WindowsFormsHost>
</Grid>
</Window>
There is the WindowsFormsHost class, though I would add a note of caution. If you're using all your old controls from winforms, mixed with WPF, it won't be a nice experience for the user. I assume you've been told you can't, or don't have time, but really you should look to replacing your existing controls with WPF controls. Unless you have lots of seriously complicated owner-drawn stuff, this shouldn't be too much effort.
So my recommendation would be to start creating WPF versions of your existing controls (or buy a set from someone like Telerik for any non-domain-specific controls you've created, like toolbars etc), and only keep Winforms controls for extra-complicated bespoke controls you've created. Even then, you should be planning for a "phase 2" to replace those as well. Your users will thank you for it.