User and Custom Controls

[jarnmo]

Feel free to comment and discuss User and Custom Controls here.

What are they good or bad for? Good practices in using them? What kind of issue have you run into? What are the alternatives?

Any thoughts are welcome!

[jarnmo]

My experience with User and Custom Controls is what you can read from various sources online as well: Custom Controls are a bit more tedious to create but have better reusability. If you want to share your controls between projects, Custom Controls are the only option.

Now, I've also heard and read that Custom Controls are a lot faster at runtime. For example someone has done a test here: http://stackoverflow.com/questions/16847772/performance-usercontrol-customcontrol . I haven't tested this myself, and haven't heard a confirmation from an official source. Would love to hear more about the possible performance differences.

[jarnmo]

Olli Salonen from Futurice had the following comment on the topic:

Use user controls by default, but switch to using custom controls when you need to use multiple copies of a control, for example in list. The reason for this is that every instance of a user control requires a new run of loading and parsing of its XAML code. However, if you only need 1-3 copies of a control, you should probably be using a user control because the XAML template for a custom control needs to be embedded in the generic.xaml file which gets parsed during application startup. So the tradeoff is

User controls

• Simple to implement
• No impact on startup time
• Expensive to instantiate

Custom controls

• Cheaper to instantiate
• Slows down startup
• More complicated to implement

A Windows 8 app was created to compare the performance. The app adds 100 copies of identical user and custom controls to a StackPanel (to make sure virtualization is not affecting measurements). The contents of each control was as follows:

<StackPanel>
    <TextBlock>1</TextBlock>
    ...
    <TextBlock>20</TextBlock>
</StackPanel>

The cost of creating all custom controls was 20 ms compared to user controls which took 120 ms. The more complicated the XAML, the larger the difference.

[jarnmo]

if you only need 1-3 copies of a control, you should probably be using a user control because the XAML template for a custom control needs to be embedded in the generic.xaml file which gets parsed during application startup.

Actually in What's New in XAML (for Win 8.1) at BUILD 2013 they mention that keyed static resources (the ones using x:Key attribute) are now only parsed when they are needed for the first time. This makes Custom Controls even more powerful.

Additionally in XAML Performance Fundamentals, it is mentioned that all XAML for User Controls is parsed and loaded when the control is loaded, even if the control is Collapsed. For Custom Controls the XAML is only loaded when the template is applied, which doesn't happen if the control is collapsed. So in cases where you have controls whose Visibility might never get set to Visible, Custom Controls have significantly better performance.

[pcolmer]

I'm concerned about https://github.com/futurice/windows-app-development-best-practices#do-not-hardcode-a-name-for-your-custom-controls. The text actually makes reference to user control as well as custom controls, so it isn't immediately clear whether this really is just about custom controls or both.

Maybe I'm misunderstanding this best practice. Where could you set the control's Name property with a fixed value such that this would break? An example of what not to do would be very helpful :)

[jarnmo]

@pcolmer for both user controls and custom controls you could hardcode the Name of the property by basicly doing this.Name = "yourhardcodedname" in the control's defining C#. However, I don't think there would really be any reason for doing so.

On the other hand, for user controls you could also hardcode it by setting the x:Name property of the root element in the control's XAML. This you might actually end up doing if you want to element bind to a property of the control itself. For example:

<UserControl
    x:Class="App1.MyUserControl1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:App1"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    x:Name="MyHardcodedUserControlName">

...
<!-- element binding for whatever reason -->
<SomeControl SomeProperty="{Binding SomeUserControlProperty, ElementName=MyHardcodedUserControlName}" />
...

However, now that I actually tried to reproduce the issue on a WinRT app, I couldn't. So I'd imagine this has been fixed and was only a problem in Silverlight apps. I'll remove the best practice from the list.