Manu Andrei
Manu Andrei

Reputation: 62

External UserControl with Bindings in WPF/C#

So, I have an UserControl which is basically a Grid with 3 different DataGrids and some Labels. Seeing how I need to use this 3 times, instead of copying and pasting the code, I thought I'd just generate it once and use it in my main window.

I have defined the UserControl as:

<UserControl x:Class="Propuestas.UI.Andrei.DGMTX"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
             xmlns:local="clr-namespace:Propuestas.UI.Andrei"
             mc:Ignorable="d"
             Height="300" 
             Width="791.496">

And I am using it in my window as such:

<StackPanel Grid.Row="2">
    <local:DGMTX/>
    <local:DGMTX/>
    <local:DGMTX/>
</StackPanel>

For some reason, it doesn't show up in the designer panel on my main window. Is there something I'm doing wrong?

Also, I would like to be able to bind based on a bound element. For example, let's say I have a class Model which has all the data that I need to represent in my UserControl. I would like to do something like

<local:DGMTX Binding = {Binding Model}/>

and then be able to bind all of the other elements in my UserControl in its code. Is there a way I could do this in XAML? Or do I have to do it programmatically?

Upvotes: 0

Views: 457

Answers (1)

user1618054
user1618054

Reputation:

There are two ways to communicate your view model to controls:

  1. As one commenter suggested, bind your view model to the data context of the user control. This enables binding everything in your view model to the inner workings of the control. Problem is the inner workings now depend on the data the object is associated with.

  2. Create dependency properties for only the ones in your view model that the user control actually needs. I personally prefer this over the first in almost 99% of all cases because you know exactly what data the control expects and you can manipulate bound data in ways unique to the control that maybe the view model isn't responsible for.

Couple things to note about designer support when creating your own controls:

  1. Visual Studio's designer still has a lot of issues when it comes to WPF. Don't believe me? Try referencing a dynamic resource defined in your main assembly in another. The designer will crash and tell you it can't be found. This isn't the actual case, however. As soon as you run the app, you will never see this exception.
  2. In order to see changes made to source reflect in designer, you have to build the project first (the project in which the control resides, not necessarily the one it's referenced in). Sometimes, "cleaning" or (with better luck in some cases) "rebuilding" the project is the only thing that updates the designer in the main project when "building" doesn't work.
  3. If after considering the latter and you still can't see anything, consider the implementation of the control. Is anything out of place? Did something accidentally get hidden? You may not think so at first and maybe it takes ten hours of frustration to succumb and check, but the little things can make all the difference.

Upvotes: 1

Related Questions