Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Visual Basic
  4. instance of usercontrol not exposing all properties

instance of usercontrol not exposing all properties

Scheduled Pinned Locked Moved Visual Basic
winformshelptutorialannouncement
16 Posts 4 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • T 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.

    T Offline
    T Offline
    treddie
    wrote on last edited by
    #7

    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.

    D T 2 Replies Last reply
    0
    • T 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?

      D Offline
      D Offline
      Dave Kreskowiak
      wrote on last edited by
      #8

      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

      T 1 Reply Last reply
      0
      • T 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.

        D Offline
        D Offline
        Dave Kreskowiak
        wrote on last edited by
        #9

        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

        T 1 Reply Last reply
        0
        • T 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.

          T Offline
          T Offline
          TnTinMn
          wrote on last edited by
          #10

          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.

          T 1 Reply Last reply
          0
          • D 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

            T Offline
            T Offline
            treddie
            wrote on last edited by
            #11

            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.

            1 Reply Last reply
            0
            • T 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.

              T Offline
              T Offline
              treddie
              wrote on last edited by
              #12

              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.

              T 1 Reply Last reply
              0
              • D 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

                T Offline
                T Offline
                treddie
                wrote on last edited by
                #13

                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.

                1 Reply Last reply
                0
                • T 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.

                  T Offline
                  T Offline
                  TnTinMn
                  wrote on last edited by
                  #14

                  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.

                  T C 2 Replies Last reply
                  0
                  • T 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.

                    T Offline
                    T Offline
                    treddie
                    wrote on last edited by
                    #15

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

                    1 Reply Last reply
                    0
                    • T 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.

                      C Offline
                      C Offline
                      compitionpoint
                      wrote on last edited by
                      #16

                      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;
                          }
                      }
                      

                      }

                      1 Reply Last reply
                      0
                      Reply
                      • Reply as topic
                      Log in to reply
                      • Oldest to Newest
                      • Newest to Oldest
                      • Most Votes


                      • Login

                      • Don't have an account? Register

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • World
                      • Users
                      • Groups