Question

Ok, i think i’m missing something here.

Lets say, in a Winforms application i have a Form and a UserControl. I then add a Button to the UserCntrol, and then add the UserControl to the Form. Now the Button is added to the UserControl as a private member and until the UserControl exposes it’s private member through public property, the Form shouldn’t have access to the Button.

private void Form1_Load(object sender, EventArgs e)
{
    this.testUserControl1.
}

You won’t find the UserControl’s Button from the Form’s code. From the encapsulation point of view, i think this is exactly what we want.

Now lets say, i’m doing the same thing in a WPF application with a Window and a UserControl. I add a Button to the UserControl through Xaml and then add the UserControl to the Window. But now i can have access to the Button from the Window’s code.

private void Window_Loaded(object sender, RoutedEventArgs e)
{
    this.testUserControl1.button1.Content = "What the HELL!";
}  

If i add the Button through code instead of Xaml, i still have the chance to make it private. But “building the UI declaratively, NOT through the code” – isn’t that’s why Xaml is there? Then isn’t it breaking the concept of Encapsulation?

EDIT : I know most of us, including myself, use MVVM to develop WPF applications where you don’t need to refer to your UI elements from your code-behind. But the context of the question still holds, right? I often build re-usable UserContolr (not as a View as in MVVM) to use them through out several Views as visual element, where i most often than not need to use the code-behind of the UserControl.

Answer 1

I’m not really sure what you’re saying. You can make the Button in XAML and have it be private as well:

<Button x:FieldModifier="private" x:Name="Whatever" Content="This is a button" />

You don’t have to do it through code. Just it defaults to (I think) internal rather than private. But like H.B. said, I rarely name my controls anyway, so I haven’t run into this myself.