instance of usercontrol not exposing all properties

[treddie]

OK...It looks like that is the case. According to MSDN, constituent controls' properties are Private and must be exposed manually by creating Public Properties with the Get and Set accessors.

[treddie]

HEHEH...Now I'm not so sure. When I tried accessing the properties of the CONSTITUENT control in the UserControl, I was able to get to the properties, like: UserControl1.TreeView1.Nodes.Find

[TnTinMn]

If you want designer support, you would need to expose the control via a property and then write your own CodeDomSerializer to write to the form.designer.vb file.

[TnTinMn]

That is probably because your UserControl is defined in the same project as you are working in. The default access modifier is "Friend" so you can see it as long as you are working in the same assembly. If you move the UserControl to a library, you would not be able to access it unless you modified it's access modifier to "Public". Take a look at your UserControl1.Designer.vb file.

[treddie]

Yes, it is definitely 'Friend" and in the same assembly, not a dll. But for the future then, if I compile a usercontrol class into a library, declare it as Public, then, right?

[treddie]

Hold on though. I thought the whole idea of a usercontrol was to be able to access all of its properties just like any other control, even if that control has consituent controls inside it. I am curious as to why it is so difficult to get to those properties.

[Dave Kreskowiak]

That depends on your requirements. Most of the time, you don't need to exposes the ENTIRE set of properties of the constituent control(s). You can supply properties to expose only the control properties you need or none at all and write your UserControl properties and methods to control the constituent controls internally.

A guide to posting questions on CodeProject[^]
Dave Kreskowiak

[Dave Kreskowiak]

The point behind a UserControl is to create a custom control with a bunch of other controls as children, all working as parts to solve a common goal. For example, a TextBox and a button next to it can be placed in a UserControl. The TextBox can be ReadOnly and the button is clicked, opening a OpenFileDialog that lets the user pick a path and you can then put the path into the TextBox and have that path returned as a property of the UserControl. The user does not get to type in the TextBox. The only property the UserControl would expose would be the path selected, not any of the properties of the TextBox or Button.

A guide to posting questions on CodeProject[^]
Dave Kreskowiak

[TnTinMn]

Sorry, I did not think that one over enough before posting it. You would not need a custom serializer if you exposed the child control's properties as properties of the UserControl. Basically it comes down to the fact that you need to write some code to expose properties of the children controls in the VS designer. As for your comment, Dave's response says it very well. The only thing that I would add to that, is that the usercontrol template facilitates the visual design process. Also, here is good article on the subject link.

[treddie]

In that regard, it dawned on me after I wrote that that if you had 4 constituent controls in a usercontrol, that is a hell of a lot of properties to have to expose, especially since many of those properties have the same names for different controls...A big mess when you really aren't concerned with those properties outside the user control.

[treddie]

Thanks for that info, and the great link. So basically, declaring properties is the only way to get those properties to the user. Which is great from a control management point-of-view, but necessarily a lot of work, if for some hypothetical reason, you needed to expose all the constituent controls' properties. But, now that I've been thinking about this and reading all of your replies, it's hard to imagine why that scenario would even exist.

[treddie]

I basically came to the same conclusion after I started thinking about it. Each constituent has a ton of properties you would never want to even see from a user control point-of-view.

[TnTinMn]

Quote:

So basically, declaring properties is the only way to get those properties to the user.

Not exactly. And I don't know why I did think of this earlier. :sigh: :confused: Assume you place the UserControl in a class library. As previously mentioned, you could change the child control's access modifier to Public and it would show up in the property grid and you could try to set it's properties. They would appear as set in the designer, however any of the changes are only held in Visual Studio's memory and not written to disk as part of the designer generated code. Building the project would clear any of these apparent property changes. To avoid confusion in the designer, I would set the access modifier to private and expose it through a property like this:

<System.ComponentModel.DesignerSerializationVisibilityAttribute(System.ComponentModel.DesignerSerializationVisibility.Content)> _
<System.ComponentModel.Browsable(True)> _
Public ReadOnly Property ExposedTreeView As TreeView
Get
Return TreeView1
End Get
End Property

This allows you to reference the child control in both code and via the property grid for the placed UserControl. The magic is in the DesignerSerializationVisibilityAttribute. It tells the designer to write the changes to the Form.designer.vb file.

[treddie]

I'll take a gander at that one. Sounds nice and elegant.

[compitionpoint]

You need to expose the properties you want to modify in your user control. For example, to change the column count property of the table layout control, from your user control, you have to expose the ColumnCount property: c# Control

public partial class UserControl1 : UserControl
{
public UserControl1()
{
InitializeComponent();
}

public int ColumnCount
{ 
    get
    {
        return this.tableLayoutPanel1.ColumnCount;
    }

    set
    {
        this.tableLayoutPanel1.ColumnCount = value;
    }
}

}