VS 2005 - Are control arrays back?

I looked over the beta site, but did not see anything about control arrays. Someone here mentioned that they were putting them back in 2005. Does anyone know?

Thanks!

Hi.

In practice they have never left!

Consider naming your control events Control1, Control2 etc.

e.g.

VB Code:

Private Sub Control1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

Then, say, select the number allocated to the control you want to fire, store it in a string variable and then concant it on to the string "Control" and then add the event name,
so that you end up with, say, (if using Buttons)

VB Code:

Dim strTest As String = "Control1_Click"

Then

VB Code:

CallByName(Me, strTest, Microsoft.VisualBasic.CallType.Method, Sender, e)

You have then performed the click event of Button1

(I guess you guys have noticed that I've gone mad on the CallByName function:wave: )

If you open the folowing link:
http://dotnet.mvps.org/dotnet/faqs/d...ynameindex.txt
you'll see at the very bottom:
In VS.NET "Whidbey" (2005) control arrays will be supported natively.

I have no clue who's site is that but I will be one very happy camper if that's going to happen. ;)

Taxes, you and that CallByName ...:p

In reality control arrays are not supported in any version of Visual Studio .NET (including the upcoming 2005). But, there are many ways to mimic them, one such example is the one provided by our esteemed colleague Taxes, but there are other ways to do them as well. Another member of the forums (spoiledkid) provided this insightful example wich will work across forms and controls.
Interfaces and calls

Additionally there are several examples on MSDN that will help you including this one I found by Deborah Kurata (most vbers who have been around a while will recognize this name)
Life Without Control Arrays in Visual Basic .NET

In closing, control arrays are gone (probably for good) but the loss of them cannot ever be compared to the gains we have with the .NET environment.

Quote:

---

Originally posted by taxes
Hi.

In practice they have never left!

Consider naming your control events Control1, Control2 etc.

e.g.

VB Code:

Private Sub Control1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

Then, say, select the number allocated to the control you want to fire, store it in a string variable and then concant it on to the string "Control" and then add the event name,
so that you end up with, say, (if using Buttons)

VB Code:

Dim strTest As String = "Control1_Click"

Then

VB Code:

CallByName(Me, strTest, Microsoft.VisualBasic.CallType.Method, Sender, e)

You have then performed the click event of Button1

(I guess you guys have noticed that I've gone mad on the CallByName function:wave: )

---

Screw that.... here's another way:
Create the function that will handle the call:

VB Code:

Private Sub MyButtons(ByVal sender As System.Object, ByVal e As System.EventArgs)

Then add all your controls to the handler.

VB Code:

Private Sub MyButtons(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click, Button2.Click, Button3.Click, Button4.Click, Button5.Click, Button6.Click, Button7.Click

Usign this allows you to have a different sub for events in case you need to handles all buttons except couple for special cases.

TG

Quote:

---

Originally posted by CyberHawke
... In closing, control arrays are gone (probably for good) but the loss of them cannot ever be compared to the gains we have with the .NET environment.

---

The loss is huge and irreplaceable. Many believe that "architects" at MS did realized that and concider it as a serious mistake.

BTW, Kurata's sample is nothing more than work arround.

I guess it's all a matter of perspective, I consider the loss to be insignificant with the ability to manage your controls using other methodologies. As Deborah stated, you simply need to learn the new way of doing things. Those that can adjust will and those that cannot . . . :afrog:

I believe that's called "Natural Selection" and "Evolution"......

TG

I dont really understand the big deal about there being no control arrays....

Using AddHandler and RemoveHandler you have more power than you did with control arrays, sure it isnt as easy to design and requires more coding but it doesnt seem like something to moan and complain about.

And if you really wanted

VB Code:

Dim aControlArray() as Control

Now you can access it like you would have before... the only extra work is wiring up the events and adding the controls to the array...

Sample....

Add Any Number of TextBox's to your form and do not change any name properties.

VB Code:

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
        For Each t As TextBox In Me.Controls
 
            If t.Name.StartsWith("TextBox") Then
                AddHandler t.Click, AddressOf ControlArray_Click
                AddHandler t.KeyDown, AddressOf ControlArray_KeyDown
'EDIT: For those of you who want their control array..
                  Redim Preserve aControlArray(aControlArray.Length)
                  aControlArray(aCOntrolArray.Length -1) = cType(t, Control)
            End If
        Next
    End Sub
 
    Public Sub ControlArray_Click(ByVal sender As Object, ByVal e As System.EventArgs)
        MsgBox("Clicked")
    End Sub
 
    Public Sub ControlArray_KeyDown(ByVal sender As Object, ByVal e As KeyEventArgs)
        MsgBox("KeyDown")
    End Sub

VB.Net Allows you to have explicit control over your control 'arrays'

you can wireup as may event as you want and have the other events (that arent used in other controls) work on the individual controls without large select cases or if statements.

I think this is way more powerful than Control Arrays.

Agreed :afrog:

Ahmen!
:thumb:

TG

Hi.

My 2 cents...When I first switched over to NET I was devastated. Where had the controlarray gone? I couldn't live without it...or so I thought.
Once I learned how to add handlers dynamically, I turned my back on controlarrays.

So as some of the posts above states;

Quote:

---

techgnome: I believe that's called "Natural Selection" and "Evolution"......

TG

---

Quote:

---

RhinoBull: The loss is huge and irreplaceable. Many believe that "architects" at MS did realized that and concider it as a serious mistake.

---

Rhino: That is so untrue...As many of the posts say, it's just a matter of learning to think in another way.
The only mistake is making the controlarray in the first place.
It should have been like this from day 1.

Quote:

---

Originally posted by RhinoBull
The loss is huge and irreplaceable. Many believe that "architects" at MS did realized that and concider it as a serious mistake.

BTW, Kurata's sample is nothing more than work arround.

---

No, I dont really think so. The guys at MS were just more worried in creating a solid version of VB.NET to start with, and only AFTER that are worring about puting this kind of things back.

If you want to know my opinion, I really dont see a point of doing this, unless to help newcomers to vb.net who are lazy to switch to .net ways

I'll code to that :thumb:

Hi ABX,

I tried your code and

For Each t As TextBox In Me.Controls

results in the error message

Additional information: Specified cast is not valid.

Shouldn't there be a CType in there somewhere?

Hi techgnome,

Sorry, but apart from the cumbersome number of handles if there are a lot of controls, how does your suggestion allow for different coding actions in response to each different control?

Taxes,

If you need different code for each instance of a text box in your control array, then why would you want a single event handler?

You either have branching in your method or you have separate control event handlers, either way the result is the same.

Quote:

---

Originally posted by taxes
Hi ABX,

I tried your code and

For Each t As TextBox In Me.Controls

results in the error message

Additional information: Specified cast is not valid.

Shouldn't there be a CType in there somewhere?

---

What controls did you put on your form.... i did test it... just not with anthing other than textboxes on the form. :blush:


Here is a modified version that does work properly...

VB Code:

For Each c As Control In Me.Controls
 
            If TypeOf (c) Is TextBox Then
                Dim t As TextBox = CType(c, TextBox)
                If t.Name.StartsWith("TextBox") Then
                    AddHandler t.Click, AddressOf ControlArray_Click
                    AddHandler t.KeyDown, AddressOf ControlArray_KeyDown
                End If
            End If
 
        Next

Quote:

---

Originally posted by PT Exorcist
No, I dont really think so. The guys at MS were just more worried in creating a solid version of VB.NET to start with, and only AFTER that are worring about puting this kind of things back.

If you want to know my opinion, I really dont see a point of doing this, unless to help newcomers to vb.net who are lazy to switch to .net ways

---

I agree . :)

Hi ABX,

But that's not the point. What we are trying to do here is simulate a Control Array. What you are doing is to create at runtime one click event to handle all the textbox click events.

What Control Arrays did was to allow coded reference to any control in a group of controls of the same type by reference to an index number.

Hi Cyberhawke.

Where did I say I wanted a single event handler? That was not the object of having a Control Array.

Quote:

---

Originally posted by techgnome
Screw that.... here's another way:
Create the function that will handle the call:

VB Code:

Private Sub MyButtons(ByVal sender As System.Object, ByVal e As System.EventArgs)

Then add all your controls to the handler.

VB Code:

Private Sub MyButtons(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click, Button2.Click, Button3.Click, Button4.Click, Button5.Click, Button6.Click, Button7.Click

Usign this allows you to have a different sub for events in case you need to handles all buttons except couple for special cases.

TG

---

What has that got to do with simulating Control Arrays?

Quote:

---

Originally posted by taxes
What Control Arrays did was to allow coded reference to any control in a group of controls of the same type by reference to an index number.

---

Why do you need the index number anyway? All you really need is a reference to the control!?!.

If you really really really want it with index numbers add all the controls you want in the array to a panel. Then you could just use Panel.Controls(Index).

Maybe I'm missing the point here. If so sorry.
It's just that since I learned how to use handlers and such, I have never had the need of knowing the index number of just about anything.

Quote:

---

Originally posted by pax
Why do you need the index number anyway? All you really need is a reference to the control!?!.

If you really really really want it with index numbers add all the controls you want in the array to a panel. Then you could just use Panel.Controls(Index).

Maybe I'm missing the point here. If so sorry.
It's just that since I learned how to use handlers and such, I have never had the need of knowing the index number of just about anything.

---

With a Control Array you could allow a user to select an item from a list of any sort and in one segment of code use the index number associated with that choice to go straight to the procedure you wanted to link to that choice, thus avoiding a large Select Case or If ... ElseIf ....ElseIf... etc. I can't understand why so many contributors are confusing this with having several handles to one event - That is exactly the opposite of a Control Array. There are several ways left in VB.NET to simulate Control Arrays depending on which facet of Control Arrays you wish to emulate. What is quite clear from this thread is that many people have never used a Control Array, so obviously they are not going to miss them.

I used the control array all the time, but I still don't miss it.
If you need to make e.g. a listbox you could add the control itself as an item, and just set the DisplayMember of the listbox to display the name of the control or the text or whatever.
Then all you'd have to do is DirectCast or CType the SelectedItem property of the listbox.

You can also add the control to the tag property of any other control that has a tag property. This way you will always carry a reference to the relevant control with you.

Granted, there could be situations where a controlarray would be nice, but I honestly can't think of any atm.

Hi pax,

Fine. As I said there are several ways to work around Control Arrays, but they all involve more coding. Control Arrays were very convenient, but not a necessity.

As I have said in another thread, I very much miss the DOS facility of Macro Substitution which in one short function provided the facilities of objects, Collections, Control Arrays and CallByName, but VB.NET has many other advantages.

Fair enough. :thumb:
Let's leave it at that..:p
Otherwise the mods might close it for us, as this is going into chit chat.

Quote:

---

Originally posted by <ABX
What controls did you put on your form.... i did test it... just not with anthing other than textboxes on the form. :blush:


Here is a modified version that does work properly...

VB Code:

For Each c As Control In Me.Controls
 
            If TypeOf (c) Is TextBox Then
                Dim t As TextBox = CType(c, TextBox)
                If t.Name.StartsWith("TextBox") Then
                    AddHandler t.Click, AddressOf ControlArray_Click
                    AddHandler t.KeyDown, AddressOf ControlArray_KeyDown
                End If
            End If
 
        Next

---

One problem I see with most code examples for looping through the controls collection in this thread is that nowhere does anyone take into account the possibility that a control may be a container control for other controls eg. a panel or tab, the code in the examples provided would never get a reference to those controls that are contained in other controls.

This code will access those controls, you would of course need to add further levels of nesting for each additional level of nested controls. eg, panel contains a groupbox which contains several checkboxes or radiobuttons.

VB Code:

For Each c As Control In Me.Controls
            If TypeOf (c) Is TextBox Then
                Dim t As TextBox = CType(c, TextBox)
                If t.Name.StartsWith("TextBox") Then
                    AddHandler t.Click, AddressOf ControlArray_Click
                    AddHandler t.KeyDown, AddressOf ControlArray_KeyDown
                End If
            ElseIf c.Controls.Count > 0 Then
                For Each childC In c.Controls
                    If TypeOf (childC) Is TextBox Then
                        Dim t As TextBox = CType(childC, TextBox)
                        If t.Name.StartsWith("TextBox") Then
                            AddHandler t.Click, AddressOf ControlArray_Click
                            AddHandler t.KeyDown, AddressOf ControlArray_KeyDown
                        End If
                    End If
                Next
            End If
        Next

Taxes,

Years ago I used control arrays in like VB3 or maybe 4, but I haven't had much need of them as of late, I never personally found them very useful, so your comment about not missing them is right on target.

Thanks for the great discussion.

Not missing Control Arrays really isn't the point either. In my situation, I have to convert a 40,000 line VB6 program to VB.NET. If the new version (2005) brings back Control Arrays then the Upgrade Wizard might do a better job of converting the TONS of Control Arrays that already exist in this project.

Not missing Control Arrays in a new or small project is ok, but for those that have to do conversions on large and complex projects this might be a big issue.

Well, alllllllrighty then, the bottom line is, Control Arrays are not going to be part of 2005, but with the solutions offered in this thread, you can find a way to work around not having them. :wave:

Quote:

---

Originally posted by birthjay
Thanks for the great discussion.

Not missing Control Arrays really isn't the point either. In my situation, I have to convert a 40,000 line VB6 program to VB.NET. If the new version (2005) brings back Control Arrays then the Upgrade Wizard might do a better job of converting the TONS of Control Arrays that already exist in this project.

Not missing Control Arrays in a new or small project is ok, but for those that have to do conversions on large and complex projects this might be a big issue.

---

Why didn't you say so earlier???

Control Arrays ARE fully available in VB.NET but ONLY to be used in upgrading from VB6. It is in the Microsoft Visual Basic .NET Compatibility library.:bigyello:

Taxes,

Those aren't .NET controls, they are ActiveX controls that have been wrapped for use in the .NET environment.

As I have stated in more than one thread, The upgrade wizard is a disappointment at best, a delusion at worst.

You are better off grasping the concepts of what your software does, building business rules based on those concepts and re-writing your .NET solution from scratch.

And he did say so earlier :)

converting a 40k line VB6 project to VB.NET is not realistic.. rewriting a 40k line VB6 project using VB.NET would be a better solution... otherwise whats the point of going to .net??? you need to rewrite the code to use the new functionality .net has to offer

Quote:

---

Originally posted by CyberHawke
Taxes,


And he did say so earlier :)

---

OH NO HE DIDN'T!!!!!!!!!!!

(OOps! Perhaps, as a yankee, you don't understand allusions to English pantomime.)

As a yankee, we don't know even what a pantomime is.... we don't have them.... perhaps we should have some..

Quote:

---

Originally posted by nemaroller
As a yankee, we don't know even what a pantomime is.... we don't have them.... perhaps we should have some..

---

Maybe you don't know it but you have a great pantomime every time George Bush goes on television:bigyello:

(actually I'm one of his fans:wave: )


For the uneducated, a pantomime is a play performed at Christmas in which everything is reversed. Men play women and women play men, with lots of ridiculous goings on and crummy jokes, with the audience getting vocally involved, but all decent family entertainment.

hey, I want pantomimes:o

uhhhh... what are they again:confused:

Just a curiousity question...

Why is it better to rewrite a 40K VB6 program in VB.NET rather than using the wizard? If I use the conversion, it pretty much maintains all my forms and pratically most of the code. It seems I can go back and edit the code to conform to .NET and as far as the COM and DLL woe's why can't I convert that at a later date?

It would seem the time saving alone in recreating the forms is a biggie.

The overall question is....can't I add and delete code and components to conform to .NET after the project has been converted?

oh yeah....and I probably did not mention that I was doing a conversion in this thread, but I posted another thread on that topic about the same time as this one.

Thanks!

A 40,000 line app would be stupid to convert (no offense).

If it works, why would you want to deal with the post-conversion headaches with an app that big?

Quote:

---

oh yeah....and I probably did not mention that I was doing a conversion in this thread, but I posted another thread on that topic about the same time as this one.

---

Explains why I knew you were converting it. :D

Quote:

---

Why is it better to rewrite a 40K VB6 program in VB.NET rather than using the wizard? If I use the conversion, it pretty much maintains all my forms and pratically most of the code. It seems I can go back and edit the code to conform to .NET and as far as the COM and DLL woe's why can't I convert that at a later date?

---

When you use the conversion wizard, you end up with a VB6 project that can be executed from a .NET wrapper. but the code, controls, etc are all VB6, ActiveX, COM, yada yada. So it isn't a ".NET" program, just one that runs within the .NET framework.

You receive none of the benefits of .NET and your resulting program could have potential security issues because you are relying on COM interop to activate your controls and run a good portion of your code. That's why I made the statement that the conversion wizard is a delusion, it gives you the illusion that you have a .NET program when in fact, you don't!

Thanks folks.

Are there any articles at Microsoft (or elsewhere) that support what has been said here?

Thanks!

CyberHawke is correct. http://vr6.pharfruminsain.com/VWVortex/thumbsup2.gif

Besides,... converting a 40,000 line VB6 project into VB.NET is the reason we have jobs! :D

Take advantage of the opportunity to improve the application by converting it yourself. I'm sure you'll easily find many new ways that the program will work better and smarter with all the improvements .NET provides.

Pantomimes and Americans...
"few years ago, when I first started using the Internet, I was corresponding with a young lady from America. In the course of conversation I mentioned that I had to leave to go and rehearse for this year's panto. The lady in question didn't have any idea of what I was talking about. I am again in the middle of rehearsals for panto, and thought this might be an opportune moment to explain, where necessary, the great British tradition of pantomime.
"
http://gouk.about.com/cs/theatre1/a/pantos.htm

I am no fan of Gee What Bush btw...

Quote:

---

Originally posted by birthjay
Thanks folks.

Are there any articles at Microsoft (or elsewhere) that support what has been said here?

Thanks!

---

Not quite sure what you are asking.

Look at Control Arrays in MSDN Help (2003 version)

Quote:
" Visual Basic .NET and C# allow you to duplicate some of the functionality commonly associated with control arrays. For example, you can use delegates to bind events from multiple controls to a single event handler. However, it might be more convenient to incorporate that functionality into a single dynamic, easy-to-manage component. In this article you will create a component that uses the following:

A collection to index and sort your controls. A collection of buttons will be used for demonstration purposes.
An event handler to handle the click event from your derived button.
Code to allow referencing the control and its members by index.
Code to dynamically add and remove controls from your form. "

You're driving this thread crazy ! Control arrays suckx . This is my 2cent . :)

Quote:

---

Originally posted by Pirate
You're driving this thread crazy ! Control arrays suckx . This is my 2cent . :)

---

If it bothers you that much - simply don't get involved.
So far all responds were leading toward WORK ARROUNDs especially by CyberHawke. The whole point of having ControlArray is be able to reference group of controls by INDEX and someone's already pointed it out. Instead of such extremly simple way we have to do all that nonsence discussed in this thread and beyond.

Regardless of any inputs, opinions and whatever - Control Array is one very powerfull feature .NOT could have !!!

Quote:

---

Originally posted by RhinoBull
Regardless of any inputs, opinions and whatever - Control Array is one very powerfull feature .NOT could have !!!

---

As I said before, those who can adapt will, and those who cannot ....

Control Arrays offer no specific benefit which is why the engineers at Microsoft decided to drop support for them, it was not an oversight, it was intentional.

btw, most of the posts I have made to this increasingly indigestible thread had to do with re-writing your VB6 code into VB.NET code in lieu of using the upgrade wizard . . and I'm not gonna rehash that again.

Finally if you consider it .NOT, then why are you using it?
I have been using VB since before it was even called VB, I think I still even have a set of the two original disks (floppies) that version 1.0 came out on laying around here somewhere :p

I've watched VB mature over the years, gaining functionality and adding support for developer requests eg. database support v3, and OO support, v5, to finally fully supporting OO in the .NET release 1.0. If anyone thinks that pre-.NET versions of VB are better than the .NET offering, by all means, be my guest, please do continue to use them. For many who could not make the transition from COM to the .NET framework this will ultimately be their only course of action. For those who are just starting out in the developer community, I suggest that you not waste your time with pre-.NET versions and go straight into .NET, this way you won't have to un-learn a bunch of bad habits like control arrays and non-OO develpment practices. For those of us who have been with VB for the long haul, if you can make that transition from COM to the .NET framework, I raise my glass to you, it is a considerable leap but one well worth taking.

I enjoy posting in these forums and I enjoy helping young developers begin their walk down that path that, for many, offers a challenging and rewarding career or hobby. I hope that the posts that I have made have truly been benificial. If they have not I will do my utmost to do a better job in the future.

This is a great bunch:thumb:

Let's get straight, CyberHawke.
I how to use .NOT since it's first beta and wasn't then nor I'm now trilled with it. It's ok type language. Point is - it's not Visual Basic anymore (pure java in vb's shell).
Second thing is that I'm in this buisness for about 20-25 years with few breaks at some points and VB is the language of my choice since the beginning. I've seen alot of different tools and let me tell you: VB6 is still the best language out there and it's complitely bizzare to ignore this fact. VB.Not or C# are yet to proove themselves. Control Array is just a small drop in the ocean that MS produces just to make money and nothing more than that. They came out with VC++ and MFC became over the sudden the most powerfull tool labrary, then it was VB5 turn and many forgot C programmers switched to VB due to its simplity coding wise. What we see now is opposite transition - instead of simplifying things MS decides to compicate the hell out it.
Learning curve and everything that comes along are part of any transition so VB.NOT is no different.

I think I'm done with this thread.
Best of luck and Cheers.

Your grasp of the English language is as inspiring as your ability to spell.

Regarding your comment on vb being the greatest language out there, that my friend is opinion and not one widely shared. I love vb, don't get me wrong, but it has a lot of failures and lacks a considerable amount of functionality that is supported by most other languages. VB has been for many years considered a "toy" language by those who coded in much more robust languages such as C++ and PowerBuilder. But that's fine, that "toy" language has netted me many toys over the years, so they can call it what they will, but their reasoning is sound. You just cannot do everything in VB that you can in C, C++ and the like. So calling it the best language is down right laughable. True many C developers made the jump to VB, but only for small applications that were business oriented, ever try to write a device driver in VB? how about a real game like EverQuest or Age Of Mythology? ok, how about something simple like a TCPIP wrapper, I wrote one in VB, but performance was terrible, I and several other developers attempted to make it robust enough for our purposes, but I ultimately resorted to writing it in C++ becuase VB just could not handle the call backs.

Most languages have their purposes, but VB.NET is far and above the old vb. If you have trouble making the transition, Microsoft has provided many wizards to help with doing things like data access and control creation, but what they are trying to do is turn the developer community back into good solid programmers.

btw, I have been programming since 1975, and I can't remember all the languages I've used in that time, but they have all been useful including VB (both COM and .NET).

Cheers

Quote:

---

Originally posted by RhinoBull
If it bothers you that much - simply don't get involved.
So far all responds were leading toward WORK ARROUNDs especially by CyberHawke. The whole point of having ControlArray is be able to reference group of controls by INDEX and someone's already pointed it out. Instead of such extremly simple way we have to do all that nonsence discussed in this thread and beyond.

Regardless of any inputs, opinions and whatever - Control Array is one very powerfull feature .NOT could have !!!

---

I DON'T care if any of you respond to this thread every 1 minute but it's really not worth it . If your problem has to do with naming convesion that control arrays follow then name it like this(at least it looks better than brakets) :

Code:

---

MyControl1.Blah
MyControl2.Blah
MyControl3.Blah

---

Don't misinterpret my words next time . I'm one of those whouys appreciate what everyone does here . :)

it's a great implementation of the available functionality built into the .NET framework, and is a great work around for lack of true control arrays, nice job Pirate :thumb: