Control Arrays in VB.NET

[Dan Barclay]

Pat,

On 20 Mar 2001 11:29:34 -0800, "Patrick Troughton" <NoSpam@NoSpam.com>
wrote:

>
>Tag? Ugh. If you need to add an additional property to an existing control,
>there's already a better way to do it....inheritance. Hopefully, they'll
>reconsider this one. Regardless, any other changes we can expect?

MS did not agree to any changes at the Summit, they just listened.
*Individuals* at the summit had various things to say. I can quote
you almost any opinion about any feature you wish <g> but I won't.
For the record, there was an NDA.

As to Tags, they didn't commit at the summit, but have since publicly
said they would be in Beta2. They gave Karl Peterson the go-ahead to
say this in his list of incompatibilities (see
http://www.mvps.org/vb/index.html?rants/dotnot.htm and note that the
Tags entry is crossed out).

As to the "additional property", this isn't an addition it's an
existing property. If you don't need it, don't use it.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Jonathan Allen]

> For the record, there was an NDA.
>

True, but Tag definitely was not covered by it. The presenter said something
to the effect of "tell everyone it is back so they will stop flaming me". As
far as I remember it, nothing really significant fell under the NDA.

--
Jonathan Allen


"Dan Barclay" <dbarclay@ih2000.net> wrote in message
news:kvdfbtk9quaaou31gdsjdjscfa0g9fn1em@4ax.com...
> Pat,
>
> On 20 Mar 2001 11:29:34 -0800, "Patrick Troughton" <NoSpam@NoSpam.com>
> wrote:
>
> >
> >Tag? Ugh. If you need to add an additional property to an existing
control,
> >there's already a better way to do it....inheritance. Hopefully, they'll
> >reconsider this one. Regardless, any other changes we can expect?
>
> MS did not agree to any changes at the Summit, they just listened.
> *Individuals* at the summit had various things to say. I can quote
> you almost any opinion about any feature you wish <g> but I won't.
> For the record, there was an NDA.
>
> As to Tags, they didn't commit at the summit, but have since publicly
> said they would be in Beta2. They gave Karl Peterson the go-ahead to
> say this in his list of incompatibilities (see
> http://www.mvps.org/vb/index.html?rants/dotnot.htm and note that the
> Tags entry is crossed out).
>
> As to the "additional property", this isn't an addition it's an
> existing property. If you don't need it, don't use it.
>
> Dan
> Language Stability is a *feature* I wish VB had!
> (#6)

[Patrick Troughton]

Hi Dan,

I don't wish to rehash the issue since I doubt I would be able to convince
you. Only time can do that. However, let me try to clear up one possible
misconception. My view point is not a matter of "I don't need it so I want
it removed". This just isn't so. I place a high value on design and technique.
VB.NET already has a very elegant way of enhancing a control. VB6's Tag property
is a kludge, nothing more, nothing less. While in the past this might have
been acceptable because there was no reasonable way of enhancing an existing
control, this is no longer the case in .NET. With inheritance, adding a new
property is trivial. What's more, we can give it a meaningful name (self-documenting
code - what a concept!) and even specify the exact data type - things that
are impossible with VB6's Tag. What's more, we can add as many custom properties
to a control as we want.

With compatibility thrown out the window a long, long time ago, there's little
point in hanging on to anachronisms when far better alternatives are readily
available. Who are you kidding? Adding Tag will not ease your migration issues
one iota (sp?). We all know that VB.NET is a ground up rewrite. Microsoft
has an opportunity to do it right. I don't want a language of compromises.
I don't want a language of hacks. Wouldn't you rather see Microsoft adding
*useful* features to VB.NET like operator overloading, XLM documentation,
unsigned data types, etc. than adding back pointless kludges?

OK, I'll get off my soap box, hopefully someone from MS is listening....

/Pat

>As to the "additional property", this isn't an addition it's an
>existing property. If you don't need it, don't use it.
>
>Dan

[Dan Barclay]

On 20 Mar 2001 13:09:14 -0800, "Patrick Troughton"
<Patrick@Troughton.com> wrote:

>I don't wish to rehash the issue since I doubt I would be able to convince
>you. Only time can do that. However, let me try to clear up one possible
>misconception. My view point is not a matter of "I don't need it so I want
>it removed". This just isn't so. I place a high value on design and technique.

My point is that you and I may agree on design technique, but others
may not agree with us.

>VB.NET already has a very elegant way of enhancing a control.

I agree.

>VB6's Tag property
>is a kludge, nothing more, nothing less. While in the past this might have
>been acceptable because there was no reasonable way of enhancing an existing
>control, this is no longer the case in .NET. With inheritance, adding a new
>property is trivial. What's more, we can give it a meaningful name (self-documenting
>code - what a concept!) and even specify the exact data type - things that
>are impossible with VB6's Tag. What's more, we can add as many custom properties
>to a control as we want.

I fully agree (surprise, surprise <g>).

>With compatibility thrown out the window a long, long time ago, there's little
>point in hanging on to anachronisms when far better alternatives are readily
>available.

You can say that about *any* of the changes. "It's screwed, screw it
a little more doesn't matter". Sorry, but it does matter.

>Who are you kidding? Adding Tag will not ease your migration issues
>one iota (sp?).

You are right, it won't help me much. I don't recall where (if
anywhere) I use Tag. But, that's the point. If I don't use it, why
should I want it *removed*. There are other people who do use it, and
likely for a good purpose. Just because I don't use it should I be so
arrogant as to think it should be removed?

>We all know that VB.NET is a ground up rewrite. Microsoft
>has an opportunity to do it right. I don't want a language of compromises.

Right. They have an opportunity to do it right. What you think is
right (without compromises) and what I think is right (without
compromises) are two different things. When each of the current
language features were added there was a gaggle of folks who thought
the additions were great. For the most part (with few exceptions in
fact) they were.

The *SAME* thing will occur with what you hail as wondrous
improvements in vb.net. One day *your* wonder-language will get
trashed along with all the code you wright between now and then.

My point is that there is(was) a language here. Either it is a
language or it is not. If they do not keep stability in the core
language right now it will happen again. The only difference between
now and some point in the future is time and the names of new players.

>I don't want a language of hacks. Wouldn't you rather see Microsoft adding
>*useful* features to VB.NET like operator overloading, XLM documentation,
>unsigned data types, etc. than adding back pointless kludges?

Absolutely nothing in your list is precluded with the (real) VB syntax
and behavior. Again, what you and I may consider pointless kludges
are established features. The next "rewrite" will hose *your*
established features that some kid thinks are pointless kludges.

The difference in your view of "adding back" and mine is whether we're
talking about a beta of a new language or VB. VB already had tags.
It also had a whole list of other things... all of them help make it
VB.

>OK, I'll get off my soap box, hopefully someone from MS is listening....

You are entitled to a soapbox as much as anyone else. So am I.

Dan
Language Stability is a *feature* I wish VB had!
(#6)

[Rob Teixeira]

As many are pointing out, there are definitely ways to accomplish these things
in .NET.
However, inheritance aside, I would love it if MS would make the controls
implement ICloneable, which would do a memberwise clone minus memebers like
handle. That way, I could say something like:

Dim MyButton2

MyButton2 = MyButton1.clone()

No inheritance needed, and less code to boot.
Of course, I suppose you can inherit from a control and implement ICloneable
yourself...
well, that's the beauty of .NET - don't like something? Go right ahead and
change it, you finally have full control.

-Rob

Craig Clearman <chclear@nospam.please> wrote:
>1. Dynamically adding controls and dynamically handling control
>events at runtime
>
>2. Handling multiple events on multiple controls with a single
>event handler
>
>3. Allowing more than 254 (named) controls on a Form
>
>4. Setting multiple properties on a control at once
>
>5. Creating a clone of an existing control with a default set of
>properties
>
>6. Iterating over a collection of related controls
>
>7. Being able to use a Name/Index on a control instead of just a
>name.
>

[Jonathan Allen]

I agree, that would be cool.

--
Jonathan Allen


"Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
news:3ab7d1bb$1@news.devx.com...
>
> As many are pointing out, there are definitely ways to accomplish these
things
> in .NET.
> However, inheritance aside, I would love it if MS would make the controls
> implement ICloneable, which would do a memberwise clone minus memebers
like
> handle. That way, I could say something like:
>
> Dim MyButton2
>
> MyButton2 = MyButton1.clone()
>
> No inheritance needed, and less code to boot.
> Of course, I suppose you can inherit from a control and implement
ICloneable
> yourself...
> well, that's the beauty of .NET - don't like something? Go right ahead and
> change it, you finally have full control.
>
> -Rob
>
> Craig Clearman <chclear@nospam.please> wrote:
> >1. Dynamically adding controls and dynamically handling control
> >events at runtime
> >
> >2. Handling multiple events on multiple controls with a single
> >event handler
> >
> >3. Allowing more than 254 (named) controls on a Form
> >
> >4. Setting multiple properties on a control at once
> >
> >5. Creating a clone of an existing control with a default set of
> >properties
> >
> >6. Iterating over a collection of related controls
> >
> >7. Being able to use a Name/Index on a control instead of just a
> >name.
> >
>

[Mike Mitchell]

On Tue, 20 Mar 2001 10:42:52 -0500, "Rick Barnett"
<rickb7212@hotmail.com> wrote:

>When you have visual inheritance they're not necessary. Take a look at
>Delphi.

So, what is easier? Whacking another control on a form in a control
array or mucking about with visual inheritance. Even though I'm
learning Delphi, some things in VB it just won't do easily. Select
Case is another example. The Delphi version is very underpowered.

MM

[Mike Mitchell]

On Tue, 20 Mar 2001 07:47:48 -0800, "Phil Weber" <pweber@devx.com>
wrote:

>Gary: It's not that they were "killed," it's that they were omitted from the
>.NET rewrite...

I expect George Bush could make use of this kind of double-speak: "You
aren't being killed, just omitted from society!"

MM

[Mike Mitchell]

On 20 Mar 2001 08:05:20 -0800, "Patrick Troughton"
<Patrick@Troughton.com> wrote:

>Control arrays aren't really needed in .NET, or at least they're not as useful
>as they used to be. First, VB supports delegates so you can assign the same
>event procedure to multiple controls without using a control array. Second,
>if you want to loop controls, you can assign each control to a collection
>and just iterate on that.

So, instead of being RAD, like <=VB6, you have to actually assign some
procedure to your controls to get the same effect of simply whacking
controls on to a form (or loading them at runtime) and having the
event fall out nicely and automatically. Where's the advantage?

It's also additional work to assign those VB.NET controls to a
collection, whereas if you want to loop through controls in a control
array in <=VB6 they *are* already a collection. Where's the advantage?

MM

[Mike Mitchell]

On Tue, 20 Mar 2001 11:24:53 -0500, "Matthew Solnit"
<msolnit@nospam.yahoo-com> wrote:

>Third, under WinForms it is easy to add controls at run-time (the other main use
>of control arrays).

What is hard about adding them at runtime in VB6?

MM

[Mike Mitchell]

On Tue, 20 Mar 2001 11:22:45 -0600, Craig Clearman
<chclear@nospam.please> wrote:

>Generally, the reason control arrays are not there is because they are
>hard. MS had to triage them out of WinForms framework. If you remember
>back to VB4, MS came close to dropping control arrays at that time,
>because it was so difficult to merge the event handlers from control
>arrays and non-control arrays.

In other words, it's a cop-out.

MM

[Mike Mitchell]

On Tue, 20 Mar 2001 11:10:37 -0800, "Jonathan Allen"
<greywolf@cts.com> wrote:

>Regardless of what you and Mark may think about the issue, someone MS has
>admitted that not having control arrays was a mistake that they intend to
>rectify at some point in the future. They stated that during the VB MVP
>Summit in March when they announced that the Tag and Name properties were
>being added.

I thought this was all embargoed? NDA anyone?

MM

[Mike Mitchell]

On 20 Mar 2001 11:29:34 -0800, "Patrick Troughton" <NoSpam@NoSpam.com>
wrote:

>
>Tag? Ugh. If you need to add an additional property to an existing control,
>there's already a better way to do it....inheritance.

What utter rubbish. All the Tag property is, is a simple string
variable in which to store a few snippets of data. And you're
seriously suggesting that a better way is to involve inheritance??!!!!

Talk about obfuscating and overengineering for its own sake! I've
never heard such a load of old cobblers. Lots of you have been
extolling the virtues of XML, which, nota bene, can be stored in a
string. So you could already store much more than just plain strings,
but also mini data structures (the length of the Tag was limited),
should you so wish.

My one enhancement request for VB6 tags, since apparently Microsoft
will be supporting the product indefinitely, is to make the tag
property a variant, and then I could store an array in it as well as
keeping its simple string approach for those who need only that.

MM

[Karl E. Peterson]

Hi Dan / et al. --

> As to Tags, they didn't commit at the summit, but have since publicly
> said they would be in Beta2. They gave Karl Peterson the go-ahead to
> say this in his list of incompatibilities (see
> http://www.mvps.org/vb/rants/vfred.htm and note that the
> Tags entry is crossed out).

Point of clarification. Tag has been readded to *controls*, but not components, so
it will not be there for things like Timer and ImageList. (I was asked to be clear
about this, so they don't get further flamed. <g>)

As to "Pull yer head out, Pat!"'s contention that this "isn't needed", of course it's
not. It's a convenience for folks just starting out. It significantly lowers the
"cost of entry". But then, maybe this isn't a langauge for beginners anymore. Is
it?

Later... Karl
--
http://www.mvps.org/vb

[Karl E. Peterson]

Hi Mike --

> My one enhancement request for VB6 tags, since apparently Microsoft
> will be supporting the product indefinitely, is to make the tag
> property a variant, and then I could store an array in it as well as
> keeping its simple string approach for those who need only that.

You got it. It's an Object in VFred.

Later... Karl
--
http://www.mvps.org/vb