2

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.

atiyar
  • 7,762
  • 6
  • 34
  • 75
  • 1
    Never noticed this, then again, i pretty much never name my controls and i pretty much never have code behind in windows or user-controls. – H.B. Aug 23 '12 at 21:48

1 Answers1

3

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.

Tim
  • 14,999
  • 1
  • 45
  • 68
  • as i mentioned at the starting of my question "i think i'm missing something". i didn't know there exists an `x:FieldModifier` attribute. +1 for that. thanks a lot – atiyar Aug 23 '12 at 22:08
  • [According to MSDN](http://msdn.microsoft.com/en-us/library/aa970905.aspx) you can only use that directive to make the field even more accessible by using `public` as value. – H.B. Aug 23 '12 at 22:08
  • @H.B.: so `private` is not a valid value for `x:FieldModifier`? But it works! – atiyar Aug 23 '12 at 22:12
  • @NerotheZero: Seems so, just had a [look around](http://stackoverflow.com/a/300278/546730). – H.B. Aug 23 '12 at 22:16
  • @H.B.: interstingly, the `TypeAttributes` enumeration includes a `Public` and a `NotPublic` member but no `private` when `private` works and `Public` doesn't. you need to make it `public` instead. Who knows how to use `NotPublic` :( – atiyar Aug 23 '12 at 22:31