XAML UserControl inheritance

Question

Coming from Java, I\'m really used to a common practice when it comes to make GUI components: I usually do some sort of base class which contains all the common objects for

Answer 1

Ok, let me split this into parts:

Coming from Java

Forget java. It's a really antiquated language which has not evolved since the 90's. C# is a million times better and WPF is the best UI framework up to date.

from what I've seen, java UI frameworks such as swing are conceptually similar to .Net's winforms, which has also been replaced by WPF.

WPF (and it's XAML-based brethren) are fundamentally different from any other frameworks around because of their enhanced capability for customization via Styles and Templates and support for DataBinding.

Because of this, a Significant Mindshift is required when starting on WPF.

---

I usually do some sort of base class which contains all the common objects for my GUI components and then I extend it.

In WPF, there's the Content Model, which removes the need for inheritance and other bloated unnecesary practices, by introducing the capability to put "anything inside anything".

For example, a Button can be defined like this:

<Button>
    <Button.Content>
        <StackPanel Orientation="Horizontal">
            <Ellipse Fill="Red" Height="10" Width="10" Margin="2"/>
            <TextBlock Text="Click Me"/>
        </StackPanel>
    <Button.Content>
 </Button>

which results in

There's no need to inherit from Button just to define it's content.

There is an additional advantage WPF provides and is really handy, the ContentProperty Attribute which defines what the content of the XAML tags <Button> </Button> represents. Button is derived from ContentControl, which is declared like this:

//Declaration of the System.Windows.Control.ContentControl class,
//inside the PresentationFramework.dll assembly
//...  
[ContentProperty("Content")]
public class ContentControl: Control //...
{
   //...
}

This means that the following XAML is functionally identical to the above:

<Button>
   <StackPanel Orientation="Horizontal">
       <Ellipse Fill="Red" Height="10" Width="10" Margin="2"/>
       <TextBlock Text="Click Me"/>
    </StackPanel>
</Button>

• Notice we have removed the <Button.Content> tag, because the ContentProperty attribute takes care of that.

All this is made possible thanks to a feature called ControlTemplates, which define the Visual appearance of a Control, independently of it's behavior.

---

what I'd like to do is to have the DerivedClass into the BaseClass container.

There are several ways to achieve that, one of them is to leverage ControlTemplates and define a specific container inside the XAML that will host the content:

<UserControl x:Class="BaseClass">
    <UserControl.Template>
        <ControlTemplate TargetType="UserControl">
            <DockPanel>
                <TextBlock DockPanel.Dock="Top" Text="I'm the Container"/>

                <!-- This is where the Hosted Content will be placed -->
                <ContentPresenter ContentSource="Content"/>
            </DockPanel>
        </ControlTemplate>
     </UserControl.Template>
</UserControl>

Then you could reuse this template like this:

<Window>
   <my:BaseClass>
       <Border Background="Gray" BorderBrush="Blue" BorderThickness="2"
               VerticalAlignment="Center" HorizontalAlignment="Center">
           <TextBlock Text="Im the Hosted Content" Foreground="AliceBlue"/>
       </Border>
   </my:BaseClass>
</Window>

which results in:

No need for inheritance or any procedural code stuff.

---

Another very important aspect when starting in WPF, which is extensively explained in the "Significant Mindshift" link above, is what I tell everyone here:

Learn MVVM before you ever write a single line of code in WPF

• Most of the time you don't put any code in WPF UI elements, because most things can be achieved by DataBinding (covered in the "DataBinding" link above), or by implementing Reusable Attached Behaviors or Attached Properties. Only VIEW-Specific code should be placed in code behind, which does not deal with Data or Business Logic

• The boilerplate you might be used to in other frameworks, such as:

  txtLastName.Text = person.LastName;
  txtFirstName.Text = person.FirstName;
  btnSubmit.IsEnabled = person.IsActive;
  

  and stuff like that, is completely unneeded in WPF, again, because of DataBinding.

---

Another concept which enables high flexibility when it comes to showing data in the UI is WPF's DataTemplates, which allow you to define a specific UI to be used when some Data Type is "rendered" on screen.

---

Because of all of the above, WPF is fundamentally different from most UI frameworks out there, and thus removes the need for all the horrible boilerplate and hacks which are common in other frameworks,

I suggest you read up on all the links provided and keep in mind all these concepts and practices when defining an application's structure and UI in general.

Let me know if you need further assistance.

Answer 2

As far as I know, deriving UI as is, is unavailable unless for resources XAML (styles for ex). Maybe the reason is the UI manager cannot guess where to put the extended XAML code: Imagine the base UI as follows:

<UserControl > 
 <Grid>
  <Border/>
 </Grid>
</UserControl>

and the derived UI :

<UserControl> 
 <DockPanel>
  <Button/>
 </DockPanel>
</UserControl>

What would be the result after the mix?

a straight forward answer could be:

  <UserControl > 
    <Grid>
     <Border/>
    </Grid>
    <DockPanel>
     <Button/>
    </DockPanel>
  </UserControl>

which is not possible.

What about controls embedding/compatibility issues ?