A little distraction between deep philosophy here - components property

[Miha Markic]

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

[Bill McCarthy]

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

[Miha Markic]

> 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

[Bill McCarthy]

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.

[David Bayley]

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.

[Bill McCarthy]

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>

[Sjoerd Verweij]

> > 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).

[Bill McCarthy]

"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.

[David Bayley]

> 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.

[Bill McCarthy]

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.

[David Bayley]

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.

[Bill McCarthy]

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.

[Miha Markic]

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