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!