A little distraction between deep philosophy here - components property


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 13 of 13

Thread: A little distraction between deep philosophy here - components property

  1. #1
    Miha Markic Guest

    A little distraction between deep philosophy here - components property

    Hi.

    Just to take a break.
    I am wondering, why there is no Components property of Form class. There is
    Controls property (inherited from Control class) but no Components property.
    Strangely, the Components property is created as private by the designer.
    Problems:
    1. I cannot enumerate or walkthrough the components of a Form.
    2. Every derived Form has its own components property.

    Can somebody here explain this oddity?
    Miha



  2. #2
    Bill McCarthy Guest

    Re: A little distraction between deep philosophy here - components property

    Hi Miha,

    I'll take a guess at this, and I empasize the *guess* .

    Components are not required for a winFrom app, hence they are not part of a
    winForm. You can always add a Conatiner like the VB WinForm templates do,
    but you don't have to.

    The Conatiner (ususally referred to as a variable called "components") can
    be used to ensure that components are disposed of rather than being
    implicitly disposed via their finalisers. So if you have a component that
    has a Dispose method then best to add it to your components container.

    Taking an even bigger guess, I would expect to see the winForms designer
    change a bit in later releases. Specifically I would hope that any component
    that implements IDisposible will automatically be added to the components
    container.




    "Miha Markic" <miham@spam=no.spin.si> wrote in message
    news:3a713119@news.devx.com...
    > Hi.
    >
    > Just to take a break.
    > I am wondering, why there is no Components property of Form class. There

    is
    > Controls property (inherited from Control class) but no Components

    property.
    > Strangely, the Components property is created as private by the designer.
    > Problems:
    > 1. I cannot enumerate or walkthrough the components of a Form.
    > 2. Every derived Form has its own components property.
    >
    > Can somebody here explain this oddity?
    > Miha
    >
    >




  3. #3
    Miha Markic Guest

    Re: A little distraction between deep philosophy here - components property


    > I'll take a guess at this, and I empasize the *guess* .


    Sure, at this time everybody is guessing

    > Components are not required for a winFrom app, hence they are not part of

    a
    > winForm.


    Hmm. No? All declarations are inside winForm. True, that they are not shown
    on winForm, though.

    You can always add a Conatiner like the VB WinForm templates do,
    > but you don't have to.


    Right. I don't want to, since there is already existing container.

    > The Conatiner (ususally referred to as a variable called "components") can
    > be used to ensure that components are disposed of rather than being
    > implicitly disposed via their finalisers. So if you have a component that
    > has a Dispose method then best to add it to your components container.


    I see. Good point.

    > Taking an even bigger guess, I would expect to see the winForms designer
    > change a bit in later releases. Specifically I would hope that any

    component
    > that implements IDisposible will automatically be added to the components
    > container.
    >


    Aren't they now automatically added?

    Miha




  4. #4
    Bill McCarthy Guest

    Re: A little distraction between deep philosophy here - components property

    Hi Miha,

    "Miha Markic" <miham@spam=no.spin.si> wrote in message
    news:3a714e8b@news.devx.com...

    >
    > Hmm. No? All declarations are inside winForm. True, that they are not

    shown
    > on winForm, though.
    >
    > You can always add a Conatiner like the VB WinForm templates do,
    > > but you don't have to.

    >
    > Right. I don't want to, since there is already existing container.
    >


    Okay, I think you've mis-understood me here.
    In a WinForm, you will see code such as :
    Private components As System.ComponentModel.Container

    but you don't need that in beta 1. AFAICT, it isn't used in beta 1. If you
    rem out all instances of it, it will make no difference to your app. The
    var, components, is , AFAICT, designed to be used for managing the Disposing
    of components, as opposed to controls.

    The designer does not actually add that code, is part of the
    WindowsApplication templates etc. If you change that template, say
    "C:\Program Files\Microsoft Visual
    Studio.NET\Vb7\VBWizards\WindowsApplication\Templates\1033\Form.vb" then you
    won't see the components variable being created by the designer itself.

    IOW: the "components" variable, which is a ComponentModel.Container is
    totally optional.

    I think the use of it is to make it easier to have objects dispose method
    called .


    >
    > Aren't they now automatically added?
    >


    No, not at pesent, at least not that I have noticed.

    BTW: I don't think the "components" variable is what you are after.
    Components in VB.NET, are really nothing more than controls without windows.
    However, I prefer to think of them as objects that you can add to the form
    using the designers. But you don't have to add them at desing time either,
    you can add them at run time. Hence, for a form to have a Components
    property that actually worked under all circumstances, there would have to
    be reflection calls going on everytime you added or changed a module level
    variable to check to see if the variable implements IComponent, and if so
    add another reference to it in the so-called Components property
    (non-existant for obvious reasons <g>) Imagine what would happen if you had
    an array or hashtable that you used to store the component refs in. The form
    would then have to monitor all calls to Add/Remove etc for the hashtable.

    If what you are after is the module level variables that implement
    IComponent, your best bet would be to try to use reflection as needed rather
    than try to have the form track all your variables.





















  5. #5
    David Bayley Guest

    Re: A little distraction between deep philosophy here - components property

    Bill,

    > In a WinForm, you will see code such as :
    > Private components As System.ComponentModel.Container
    >
    > but you don't need that in beta 1. AFAICT, it isn't used in beta 1.


    It is used when you add a Component though at design time.

    > The
    > var, components, is , AFAICT, designed to be used for managing the

    Disposing
    > of components, as opposed to controls.


    Right.

    > > Aren't they now automatically added?

    >
    > No, not at pesent, at least not that I have noticed.


    Huh? How else does components.Dispose() do its business?

    > Hence, for a form to have a Components
    > property that actually worked under all circumstances, there would have to
    > be reflection calls going on everytime you added or changed a module level
    > variable to check to see if the variable implements IComponent, and if so
    > add another reference to it in the so-called Components property
    > (non-existant for obvious reasons <g>) Imagine what would happen if you

    had
    > an array or hashtable that you used to store the component refs in. The

    form
    > would then have to monitor all calls to Add/Remove etc for the hashtable.


    I don't understand this Bill. A Form.Components property could work exactly
    the same way as the Form.Controls property. If you change one of the
    *design time* control variables, then you're just as screwed, as if you were
    to change one of the component variables.

    Somebody else had a problem where it wasn't possible to enumerate over the
    components collection from outside the form, and I suggested that he expose
    the components as a public property. However, that didn't really help him
    much, since he wanted a generic routine that worked with any form, and I
    suggested the same thing as Miha.

    AFAICT, a built-in Form.Components property is a great idea, especially
    since the designer needs to add a components variable anyway for design time
    support. Not only could you inspect the collection from any generic Form
    reference, but it would eliminate the need to override the Form.Dispose()
    method and tidy up the vanilla MyForm immensely. The overridden Dispose
    method, is just the sort of think that is going to put upgraders right off
    IMO (i.e. "What's all this sh*t, it was so simple in classic VB").

    Hope this signal gets through all the noise <g>.

    --
    David.









  6. #6
    Bill McCarthy Guest

    Re: A little distraction between deep philosophy here - components property

    Hi David,

    "David Bayley" <dbayley@aebacus.com> wrote in message
    news:3a71a2c4@news.devx.com...
    >
    > > In a WinForm, you will see code such as :
    > > Private components As System.ComponentModel.Container
    > >
    > > but you don't need that in beta 1. AFAICT, it isn't used in beta 1.

    >
    > It is used when you add a Component though at design time.
    >


    How so ? I haven't seen it used at all. IComponent is used, but that's the
    component that implements that. ComponentModel.Container, as far as I have
    seen has not been used. Under what conditions have you seen it used at
    design time ??


    > > > Aren't they now automatically added?

    > >
    > > No, not at pesent, at least not that I have noticed.

    >
    > Huh? How else does components.Dispose() do its business?
    >


    Well does it actually do anything in Beta 1 ????

    <snip>
    >
    > I don't understand this Bill. A Form.Components property could work

    exactly
    > the same way as the Form.Controls property. If you change one of the
    > *design time* control variables, then you're just as screwed, as if you

    were
    > to change one of the component variables.
    >


    Sure, but controls are used differently from components. In VB6 we already
    do a Load call with control arrays, so it seems reasonable that a
    Controls.Add call would or should be used in VB.NET. But components might be
    your datasets, etc. Surely you don't want to be adding/removing them from a
    components property everytime you ad or remove one of them at run time. And
    if you limit it to desing time only, then what purpose does it actually
    serve ?


    > Somebody else had a problem where it wasn't possible to enumerate over the
    > components collection from outside the form, and I suggested that he

    expose
    > the components as a public property. However, that didn't really help him
    > much, since he wanted a generic routine that worked with any form, and I
    > suggested the same thing as Miha.
    >


    Well, AFAIK, it doesn't work because they are not added to the container at
    design time anyway. Why notjust use reflection, check the fields types and
    see if the implement IComponent.

    > AFAICT, a built-in Form.Components property is a great idea, especially
    > since the designer needs to add a components variable anyway for design

    time
    > support.


    Okay you keep claiming that. Please show me where , or give a situation when
    this actually happens. I have not seen it.

    > Not only could you inspect the collection from any generic Form
    > reference, but it would eliminate the need to override the Form.Dispose()
    > method and tidy up the vanilla MyForm immensely. The overridden Dispose
    > method, is just the sort of think that is going to put upgraders right off
    > IMO (i.e. "What's all this sh*t, it was so simple in classic VB").
    >


    Well you still have to use the Dispose method for components you add. Hiding
    it is just asking for trouble. Without DF, dispose is a necessity, and not
    just in winForms. Best to get use to that one <g>
    Oh, and if you want this, then what is stopping you actually using the
    ComponentModel.Conatiner var, declaring it as public and adding the
    components to it.
    BTW: I personally see the advantage of the "components" var as something
    that will clean up those components that Implement IDispossible, which may
    or may not be all of the desing time added components.


    > Hope this signal gets through all the noise <g>.
    >


    <g>







  7. #7
    Sjoerd Verweij Guest

    Re: A little distraction between deep philosophy here - components property

    > > Huh? How else does components.Dispose() do its business?
    > Well does it actually do anything in Beta 1 ????


    If it does, it's not important :-)

    I don't use it at all. But heck, my forms are just classes now (prevents me
    from accidentally opening up the Designer and killing my form initialization
    code).



  8. #8
    Bill McCarthy Guest

    Re: A little distraction between deep philosophy here - components property


    "Sjoerd Verweij" <nospam.sjoerd@sjoerd.org> wrote in message
    news:3a71ba30@news.devx.com...
    > > > Huh? How else does components.Dispose() do its business?

    > > Well does it actually do anything in Beta 1 ????

    >
    > If it does, it's not important :-)
    >
    > I don't use it at all. But heck, my forms are just classes now (prevents

    me
    > from accidentally opening up the Designer and killing my form

    initialization
    > code).
    >


    Yep. I wish they would have a readonly section in that Initialise code .
    Something where we could manually edit it and it stay that way !!! (I reckon
    showing the code and not letting us touch it is a tease <bg>)

    BTW: you know you can just change the code type in the Project's xml file
    (.proj). Just change the file's subtype to/from "Code", "Component" or
    "Form" etc. That too I wish they would let us set in the properties window
    along with buildaction, rather than having to edit the .proj file manually.






  9. #9
    David Bayley Guest

    Re: A little distraction between deep philosophy here - components property

    > How so ? I haven't seen it used at all. IComponent is used, but that's the
    > component that implements that. ComponentModel.Container, as far as I have
    > seen has not been used. Under what conditions have you seen it used at
    > design time ??


    If you add a WinForms.Timer, components is passed in the constructor. If a
    Component requires disposing, and the designer doesn't add a call to Dispose
    in MyForm.Dispose (I don't think the designer can do that even if it wanted
    to), then I just see it as a Beta bug not to add it to components. For the
    sake of argument, I think we can assume that that is the intended use for
    components, even if every Component doesn't support it yet.

    > Sure, but controls are used differently from components. In VB6 we already
    > do a Load call with control arrays, so it seems reasonable that a
    > Controls.Add call would or should be used in VB.NET. But components might

    be
    > your datasets, etc. Surely you don't want to be adding/removing them from

    a
    > components property everytime you ad or remove one of them at run time.

    And
    > if you limit it to desing time only, then what purpose does it actually
    > serve ?


    In VB6, the non-visual ActiveX controls were the equivalent of designable
    components. I see no difference here, and it looks to me like the goal is
    to extend design time support for all sorts of components in the toolbox,
    along with the new palette (as opposed to trying to find a blank spot for
    those silly invisible boxes <g>). There was some mention of server-side RAD
    as well, but not sure if the palettes for that are done yet.

    If I add/remove them at run-time, then no, it doesn't serve any purpose.
    But at design-time, I see the benefits being the same as those for Controls.
    Double-click the toolbox, use the property-sheet to rapidly set the
    properties, and hit run! To get rid of it, select the component in the
    palette, and hit delete.

    > Well, AFAIK, it doesn't work because they are not added to the container

    at
    > design time anyway. Why notjust use reflection, check the fields types and
    > see if the implement IComponent.


    Apart from being a PITA, many components are contained by a Control rather
    than the components var, so I don't think it is practical anyway.

    > Well you still have to use the Dispose method for components you add.

    Hiding
    > it is just asking for trouble. Without DF, dispose is a necessity, and not
    > just in winForms. Best to get use to that one <g>


    At design-time, then it's the designer's responsibility. If you code a new
    component at run-time, then it's your responsibility. I agree with your
    sentiment that its best to get used to it, but no need to throw newbies or
    non-pros in the deep end, if you can provide a paddling pool eh <g>.

    > Oh, and if you want this, then what is stopping you actually using the
    > ComponentModel.Conatiner var, declaring it as public and adding the
    > components to it.


    Doesn't work with a base Form reference. Not sure why the guy wanted loop
    through all the components in the first place. I'm not saying that there
    aren't workarounds, just that a built-in Form.Components would be a much
    cleaner and more powerful design all round. Lots of pros, and no cons that
    I can think of.

    > BTW: I personally see the advantage of the "components" var as something
    > that will clean up those components that Implement IDispossible, which may
    > or may not be all of the desing time added components.


    I view it as more than that, or rather the form's container for "designable"
    components. But yes, it pretty much boils down to the same thing. You can
    add your own new components to it at run-time, just as you can add your own
    new controls at run-time to Form.Controls.

    --
    David.




  10. #10
    Bill McCarthy Guest

    Re: A little distraction between deep philosophy here - components property

    Hi David,

    "David Bayley" <dbayley@aebacus.com> wrote in message
    news:3a71cf6e@news.devx.com...
    >
    > If you add a WinForms.Timer, components is passed in the constructor.


    Thanks. My mistake. I missed that one.

    > If a
    > Component requires disposing, and the designer doesn't add a call to

    Dispose
    > in MyForm.Dispose (I don't think the designer can do that even if it

    wanted
    > to), then I just see it as a Beta bug not to add it to components. For

    the
    > sake of argument, I think we can assume that that is the intended use for
    > components, even if every Component doesn't support it yet.
    >


    Yep, okay. It seems the "design" for components is that if they need
    disposing then you have a constructor that takes the container as a param,
    and in the constructor actually ad the component to the container.


    >
    > In VB6, the non-visual ActiveX controls were the equivalent of designable
    > components. I see no difference here, and it looks to me like the goal is
    > to extend design time support for all sorts of components in the toolbox,
    > along with the new palette (as opposed to trying to find a blank spot for
    > those silly invisible boxes <g>). There was some mention of server-side

    RAD
    > as well, but not sure if the palettes for that are done yet.
    >


    In a way yes, but components are also like ActiveX dll's not just controls.


    > If I add/remove them at run-time, then no, it doesn't serve any purpose.
    > But at design-time, I see the benefits being the same as those for

    Controls.
    > Double-click the toolbox, use the property-sheet to rapidly set the
    > properties, and hit run! To get rid of it, select the component in the
    > palette, and hit delete.
    >


    Yep, I like components, but that's different from needing a components
    container that holds references to all components used and calls dispose on
    all of them.

    >
    > Apart from being a PITA, many components are contained by a Control rather
    > than the components var, so I don't think it is practical anyway.
    >


    Right and what happens if you do have a components property then for the
    form. Do all components conatianed by a control also get added to the
    components collection as well as the controls collection. Or should the
    control that contains components be responsible for calling dispose on it's
    components when it get's it's dispose called on it. I think the later is the
    way it should work, in which case the components collection of a form is
    never going to tell you all the components.

    >
    > At design-time, then it's the designer's responsibility. If you code a

    new
    > component at run-time, then it's your responsibility. I agree with your
    > sentiment that its best to get used to it, but no need to throw newbies or
    > non-pros in the deep end, if you can provide a paddling pool eh <g>.
    >


    I think the Dispose calls will be the least of their problems <g>.

    >
    > Doesn't work with a base Form reference. Not sure why the guy wanted loop
    > through all the components in the first place. I'm not saying that there
    > aren't workarounds, just that a built-in Form.Components would be a much
    > cleaner and more powerful design all round. Lots of pros, and no cons

    that
    > I can think of.
    >


    Well I see a couple of Cons. First, for it to do what he wanted, it means
    that every component needs to be added to the components property/
    (container). As you pointed out, what about controls that contain
    components. Their components property should be responsible for calling
    dispose on their contained components. It really gets messy if you try to
    force them all into the parent form's container, specially in the
    adding/removing of controls. eg: when a control gets removed, it would need
    to call on the forms container to dispose of it's components, thus meaning
    it would need to have a list of components also. And if that control is
    contained within another control...... etc..

    And then there's the question of what the components container actually
    does. I still see it's primary (only) purpose is to call dispose on the
    components. If the container has to store all components, it's then going to
    have to try to call dispose on all components whether or not they need it.


    >
    > I view it as more than that, or rather the form's container for

    "designable"
    > components. But yes, it pretty much boils down to the same thing. You

    can
    > add your own new components to it at run-time, just as you can add your

    own
    > new controls at run-time to Form.Controls.
    >


    the only pratical use for it I can see is in the calling of dispose.









  11. #11
    David Bayley Guest

    Re: A little distraction between deep philosophy here - components property

    Bill,

    > Yep, I like components, but that's different from needing a components
    > container that holds references to all components used and calls dispose

    on
    > all of them.


    If I understand you correctly, you want the option to remove the components
    var if you don't need it, either from the template, or on a case by case
    basis. I can see the advantage that it saves a bit of memory and redundant
    code for each form. I am suggesting that the components var be moved in to
    the base Form, rather than adding it to every single derived MyForm. You
    can save a bit of memory (an empty collection) by deleting it from MyForm,
    but having it built-in to the base Form saves you the code _and_ the hassle.

    > Right and what happens if you do have a components property then for the
    > form. Do all components conatianed by a control also get added to the
    > components collection as well as the controls collection. Or should the
    > control that contains components be responsible for calling dispose on

    it's
    > components when it get's it's dispose called on it. I think the later is

    the
    > way it should work, in which case the components collection of a form is
    > never going to tell you all the components.


    I agree, the latter. And that's what happens now with the components var.
    You have a tree of components (controls or otherwise), with the Form as the
    root. The *odd* thing about the components var, is that it is private and
    needs to be disposed of manually (well the template includes that horrible
    code, but you know what I mean). Every other component in the tree is
    available publicly, and disposal is taken care of by its parent.

    > Well I see a couple of Cons. First, for it to do what he wanted, it means
    > that every component needs to be added to the components property/
    > (container). As you pointed out, what about controls that contain
    > components. Their components property should be responsible for calling
    > dispose on their contained components. It really gets messy if you try to
    > force them all into the parent form's container, specially in the
    > adding/removing of controls. eg: when a control gets removed, it would

    need
    > to call on the forms container to dispose of it's components, thus meaning
    > it would need to have a list of components also. And if that control is
    > contained within another control...... etc..


    Yes, I'm not suggesting that all components in the tree be put there, just
    those whose container is the form. Like I said, I'm not sure what he wanted
    it for, but I can imagine it could come in handy...

    Say you have a bunch of forms in an app, many of which contain a number of X
    components. At the application level, you could enumerate all the forms,
    and for each one, enumerate Form.Components checking for type X components
    to do something with.

    The simplest workaround today, would be to define an IXContainer interface
    with a "Components As IContainer" property, and implement it in every Form
    that contains X components. Then in the Form loop check if it implements
    IXContainer and cast. Not impossible, just a lot more hassle.

    > And then there's the question of what the components container actually
    > does. I still see it's primary (only) purpose is to call dispose on the
    > components. If the container has to store all components, it's then going

    to
    > have to try to call dispose on all components whether or not they need it.
    >
    > <snip/>
    >
    > the only pratical use for it I can see is in the calling of dispose.


    It also allows the designer to add components to the "dispose call chain",
    as well as the developer. IOW, its not just a convenient way to "wrap" up
    all the dispose calls, which isn't really all that beneficial since you
    either have a bunch of components.Add(x) calls, or a bunch of x.Dispose()
    calls. I see the primary purpose as allowing the designer to add the
    dispose calls for you, whenever a component is drag-&-dropped onto the
    palette.

    --
    David.




  12. #12
    Bill McCarthy Guest

    Re: A little distraction between deep philosophy here - components property

    Hi David,

    "David Bayley" <dbayley@aebacus.com> wrote in message
    news:3a72f523@news.devx.com...
    >
    > If I understand you correctly, you want the option to remove the

    components
    > var if you don't need it, either from the template, or on a case by case
    > basis.



    No, not really. At present I delete it if I'm not using it, but that's more
    to do with the un-necessary code side of things <g> (That and that With
    Events Form1 <bg>)

    Actually I think we agree that the components var is for managing the
    dispose calls for components. I did another quick test, and when I added a
    timer after removing the components var, winForms still added the var to the
    Timer's constructor but didn't redeclare the components variable !! So one
    thing is for certain, what we are looking at atpresent is not the way it
    will be.

    As I said in my last post (or there abouts <g>), I hadn't noticed the
    components var added in the constructor. Considering that is the case, and
    also considering the present bug as described above, then I do agree that
    adding a Components property is probably the best thing to do. Probably best
    to add it further down the heirarchy though, either in the ContainerControl
    or Control class. Note: the Form's Controls property is actually from the
    Control class.

    The thing I don't want though is a requirement for all components added at
    design time to be added to the components collection. I just can't see much
    real benifit in that, but I can see the overhead it would cause and the
    hassles it would create by requiring you to remove from the collection etc,
    and the components collection would have to check that each object isn't
    nothing and that each object has a dispose call, all at run time, admittedly
    most likely when you are unloading a form.

    Anyway, going by the current desing it seems that only those components that
    have a constructor that takes the container param will be added to the
    components collection.

    As for the Form's Dispose, well I would still like to see that there even if
    it does only call mybase.Dispose. Ideally the compiler will realise that and
    remove the override.











  13. #13
    Miha Markic Guest

    Re: A little distraction between deep philosophy here - components property

    Hi David.

    "David Bayley" <dbayley@aebacus.com> wrote in message
    news:3a71cf6e@news.devx.com...
    >
    > If you add a WinForms.Timer, components is passed in the constructor.


    Hmm. How do I declare a constructor in that way - that IDE passes components
    as an argument.
    Does anybody know? I suppose it has to do with attributes.

    Miha



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center