So i am building an application that will have lots of windows, all with the same basic layout:
At the moment i have to recreate this structure in every window. Ideally i want this layout to be coded in a single place, perhaps into a custom Window subclass for ease of use. Does anyone have any clues for how to get started, or previous experience with similar problems?
A template describes the overall look and visual appearance of a control. For each control, there is a default template associated with it which gives the control its appearance.
A ControlTemplate will generally only contain TemplateBinding expressions, binding back to the properties on the control itself, while a DataTemplate will contain standard Binding expressions, binding to the properties of its DataContext (the business/domain object or view model).
Content Control is a base class that provides standardised functionality to WPF Controls. The Content Control class represents controls that can include a single item of content. This content is commonly plain text or a child control. Content Control is a subclass of the Control class in WPF.
Templates are an integral part of user interface design in WPF. This article explains templates, their types and how to use them in Windows applications. WPF has the following three types of templates: The ControlTemplate of a control defines the appearance of the control.
For each control, there is a default template associated with it which gives the control its appearance. In WPF applications, you can easily create your own templates when you want to customize the visual behavior and visual appearance of a control. Connectivity between the logic and the template can be achieved by data binding.
Put simply, where you declare a template affects where the template can be applied. For example, if you declare the template in the root element of your application definition XAML file, the template can be used anywhere in your application. If you define the template in a window, only the controls in that window can use the template.
[assembly: ThemeInfo (ResourceDictionaryLocation.None, ResourceDictionaryLocation.SourceAssembly)] The CustomWindow control is now ready be used. We add a new WPF application to our solution by choosing File->Add->New project on the menu bar.
You can create a new ControlTemplate that targets a window to accomplish this as shown below.
<ControlTemplate x:Key="WindowControlTemplate1" TargetType="{x:Type Window}">
<Border
Background="{TemplateBinding Background}"
BorderBrush="{TemplateBinding BorderBrush}"
BorderThickness="{TemplateBinding BorderThickness}"
>
<Grid>
<Grid.RowDefinitions>
<RowDefinition Height="Auto"/>
<RowDefinition Height="0.93*"/>
<RowDefinition Height="Auto"/>
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="0.21*"/>
<ColumnDefinition Width="0.79*"/>
</Grid.ColumnDefinitions>
<ContentPresenter
Grid.ColumnSpan="2"
Grid.Row="1"
Content="{TemplateBinding Content}"
ContentTemplate="{TemplateBinding ContentTemplate}"
/>
<ResizeGrip
HorizontalAlignment="Right"
x:Name="WindowResizeGrip"
VerticalAlignment="Bottom"
IsTabStop="False"
Visibility="Collapsed"
Grid.Column="1"
Grid.Row="2"
/>
<TextBlock Text="My Logo" />
<TextBlock Grid.Column="1" Text="My Title"/>
<StatusBar Height="20" Grid.ColumnSpan="2" Grid.Row="2"/>
</Grid>
</Border>
<ControlTemplate.Triggers>
<MultiTrigger>
<MultiTrigger.Conditions>
<Condition Property="ResizeMode" Value="CanResizeWithGrip"/>
<Condition Property="WindowState" Value="Normal"/>
</MultiTrigger.Conditions>
<Setter Property="Visibility" TargetName="WindowResizeGrip" Value="Visible"/>
</MultiTrigger>
</ControlTemplate.Triggers>
</ControlTemplate>
If you're brave enough to take a big architectural shift you could consider CompositeWPF (previously codenamed Prism) from the Patterns & Practices guys at Microsoft.
Of interest to you would be the ability to define "regions" in a shell (i.e. window) and then using views to fill the regions. It uses the Model-View-Presenter pattern to allow independent development of "views" from the model than can be easily be relocated over time as the shell only defines regions and is not coupled directly to what is placed in to it. Principally this helps decouple the shell from the views and the views from each other and make it easier to unit-test ... blah, blah blah.
It is a big jump and something that will slow you down to begin with, although your situation is one of the types of applications that CompositeWPF is meant to address.
As part of CompositeWPF you will need to take on board various patterns that can confuse newcomers, e.g. The UnityContainer, inversion-of-control, MVP (or Model/view/view-model) and dependency injection.
I can remember when I first started with the sample apps being puzzled because it is not obvious how on earth the some of the views were even being created! The unity container will instantiate objects and call parameterised constructors magically.
CompositeWPF is an elegant solution to your question but not a simple or straightforward one. Having used CompositeWPF in my last project I intend to use it again for the next appropriate application.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With