If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Re: Control Arrays in VB.NET

"Mike Mitchell" <kylix_is@hotmail.com> wrote in message <news:3aba73b0.1251638@news.devx.com>...
> So if you pass the control to a procedure, what do you do with the
> variable? The Tag obviously accompanies the control wherever it goes,
> hither and thither, from my head to my toes. Always I have the Tag.
> Your variable would have to be global? This is better than the Tag
> property?

How about creating a class inheriting from the base control and using
that instead? It could Implement an ITaggedControl interface to support
all the extra attributes you'd want. Of course, this smacks of Smalltalk
gotta-know-everything-to-do-anything class library syndrome.

--
Joe Foster <mailto:jfoster@ricochet.net> On the cans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

Re: Control Arrays in VB.NET

> The Tag obviously accompanies the control wherever
> it goes, hither and thither, from my head to my toes.

Mike: Another good example of the advantages of object-oriented programming:
a control is an object, you see, and it can be advantageous for its data
(properties) to accompany its methods.
---
Phil Weber

Re: Control Arrays in VB.NET

On Fri, 23 Mar 2001 00:42:30 GMT, kylix_is@hotmail.com (Mike Mitchell)
wrote:
>I should write a book. I'd spend some time learning VB.NET, then my
>book would have alternate chapters: Every odd chapter the cumbersome,
>unituitive, complex approach, contrasted in every even one by the
>classic Visual Basic way.

Fortunately there will be books out there which show how to do new and
interesting things with vb.net - your idea could easily be recast as:
>I should write a book. I'd spend some time learning Windows, then my
>book would have alternate chapters: Every odd chapter the cumbersome,
>unituitive, complex approach, contrasted in every even one by the
>classic DOS way.

Re: Control Arrays in VB.NET

kylix_is@hotmail.com (Mike Mitchell) wrote:
>>Am I jumping to conclusions here?
>
>Of course you are, look at IKEA! How could anyone ever imagine we can
>build furniture from those useless line drawings? Too many
>conclusions, I fear!
>
>MM

Well, much of our furniture is from IKEA, so I guess your mileage may vary.
Just a hint, though: Use the wood and fibre-board stuff in the box. The line
drawings make lousy furniture. The paper just isn't strong enough.

In fact, it's a bit like programming with a restricted set of objects and
lousy sample code. Quite a number of configurations are possible, but only
a very small number work reasonably well. And those may not always be what
the designer had in mind. However, with practice and a bit of common sense,
it will become a breeze.

Re: Control Arrays in VB.NET

John,
> >Unfortunately, GoSub is *not* deprecated. GoSub does not exist in VB.NET.
> >
>
> That doesn't do the poor fellow with all the Gosub code any good either.
> As far as he's concerned it's a distinction without a difference.

Re: Control Arrays in VB.NET

Fortunate for you that you've never used the index property in a case statement,
others have, now it's gone, not a huge loss but something that will need to be
coded around. Luckily there's always the name property <g>...

"Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
news:3ab95303$1@news.devx.com...
> That's actually the nice part. You don't have to. The click event (or whatever
> event you trap) has a parameter that is the event source object. You do not
> need an Index to get the proper object!

Re: Control Arrays in VB.NET

Hi Gary,

IMO, control "arrays" aren't needed in VB.Net. There are now new
tools/techniques, such as delegates, (visual) inheritance, and
initialization syntax, which make "code-only" UI design much easier, and
potentially faster, than using any form designer.

I concede that control array code can be shorter, but the new ways are more
consistent, and more powerful. You can add any control at runtime, adding
the event handlers dynamically; event handlers can sink events of several
controls (also, event signatures have been streamlined). For iteration over
controls, one can easily create custom collection classes, which can also be
used to create the controls and set up the handlers in a safe, consistent
way.

If this feature is to be added to (or maintained in) VB.Net, I won't object
to it. But I can't imagine I'd ever use it.

Regards,
Gregor

> Just a question:
>
> Gosub was removed because it got in someones way (made for untidy code)
>
> Lset was removed because it wasn't "safe".
>
> Wend just didn't sound right.
>
> Why were the control arrays killed?
>
> Were they not properly object oriented? Were they somehow dangerous?
>
> I've done extensive programming in VBA (EXCEL) where control arrays are
not
> available, and it is a royal pain. One of my biggest problems to port to
net
> is going to be control arrays.
>
> Any one know the story behind this?
>
> Gary

Re: Control Arrays in VB.NET

kylix_is@hotmail.com (Mike Mitchell) wrote:
>
>If VB and VB.NET each had altars, what would they be?
>
>Mine would be a rough-hewn box made from beechwood, its surface worn
>smooth from the passage of time and the touches of a million
>developers. <snip>
>
>Yep. I really think I could pray for something like that.
>

Maybe we should all pray for you!

You weren't ingesting interesting pharmaceuticals last night perchance?
Did you happen to glimpse Kublai Khan's stately pleasure dome in Xanadu?

Re: Control Arrays in VB.NET

Hi John,

I know it's a long article but it does say to not use Gosub. In particular,
notice this part....

"The GoSub statement is still provided for backward compatibility to older
versions of Visual Basic. However, the GoSub statement was not optimized
because of potential problems it can cause with the stack. Therefore, you
should not use subs of functions in your project."

I wouldn't have posted it if it wasn't a valid cite.

/Pat

"John Proffitt" <bogon@earthlink.net> wrote:
>
>"Patrick Troughton" <Patrick@Troughton.com> wrote:
>>
>>>Got a cite for developers being told not to rely on Gosub?
>>
>>PRB: Poor Performance with the GoSub Statement
>>
>>-------------------------------------------------------------------------->The
>information in this article applies to:
>>
>>Microsoft Visual Basic Learning, Professional, and Enterprise Editions
for
>>Windows, versions 5.0, 6.0
>>
>>--------------------------------------------------------------------------------
>etc.
>
>This doesn't say not to rely on GoSub. It says that the folks who implemented
>Gosub in recent version of VB didn't take the time to implement it very
well.
>
>John
>

Re: Control Arrays in VB.NET

On Thu, 22 Mar 2001 14:54:20 -0800, "Phil Weber" <pweber@devx.com>
wrote:
>On the other hand, if you think the feature set should have been frozen 3+
>years ago so that developers could have had more time to adjust to the
>changes, how can you expect MS to redesign the language at this late date?

Look at what happened with the original version of Access. Bill killed
it at the last minute.

Re: Control Arrays in VB.NET

On Thu, 22 Mar 2001 22:43:08 -0800, "Phil Weber" <pweber@devx.com>
wrote:
> > The Tag obviously accompanies the control wherever
> > it goes, hither and thither, from my head to my toes.
>
>Mike: Another good example of the advantages of object-oriented programming:
>a control is an object, you see, and it can be advantageous for its data
>(properties) to accompany its methods.

In this case, it is (was). The Tag property is very useful and right
where you need it: within the component. But it is something *I* don't
have to write. It's not the same as the chore of writing my own class
or user control and providing my own Tag property or equivalent
functionality. I don't want to waste time doing that, and also have to
spend even more time making sure that all other team members are
singing from the same hymn sheet and not going off on some tangent of
their own. With any Tag-equipped control I don't have to do anything.
I just use the control as I wish, straight out of the box, and
optionally use the Tag property. I don't have to spend time doing
Microsoft's job for them.