VB.net iterating through collections
Author
Is there any simple way I can iterate through a collecton using for i = 0 to 50 or whatever?
I have a collection of labels and a collection of buttons. I need to iterate through the collection of labels but I need each label to be related to a button next to it. So button i will be the same number as label i so I can check the value of label i and if it is 0 I can disable the corresponding button.
Right now i can only use the for each method of iterating through controls which will not work.
Enumerators?
Dim buttonCollection As CollectionDim labelCollection As Collection'Add stuff to collectionsDim labelEnumerator As IEnumerator = labelCollection.GetEnumeratorDim buttonEnumerator As IEnumerator = buttonCollection.GetEnumeratorWhile labelEnumerator.MoveNext And buttonEnumerator.MoveNext Dim label = CType(labelEnumerator.Current, Label) Dim button = CType(buttonEnumerator.Current, Button) If Integer.Parse(label.Value) = 0 Then button.Enabled = FalseEnd While
It's much easier (I guess) to put each pair of a label and a button in a panel and disable enable the panel.
Cheers
Cheers
I am not sure if VB.net, let alone VB.net 1.1 has this... but in C# you can do this (converted to vb.net):
Or something like that...
Dim c as CollectionFor i as Integer = 0 to X.Count - 1 If c is Label Then If ((Label)c).Text = "0" Then End If End IfNextOr something like that...
As a general design rule for programming, you don't want to make "parallel" collections like that. Instead, you want to create some structure that contains the "associated" items, and make a single array of those structures. Then when you iterate over that one collection, you can pass messages to the structures, which will then look at their items and do what's necessary.
In your case, you could create a class with a label and a button as members, or a subclass of button with an added label member (and other similar combinations, but those two are most likely to make sense). You give it the method for the 'consistency check': if the contained label has zero value, disable the contained button. Then you iterate over a collection of those classes, telling each to check for consistency.
Except that now we can invoke another design rule that's more OOP specific: instead of having an explicit 'consistency check' style method, the object should be responsible for keeping itself *always* in a 'consistent' state. I.e., this code really belongs in some other function that sets or changes the label value. We accept a value, set the label accordingly, and also enable or disable the button according to whether the value is zero.
If there turn out to be several methods that could affect the object "consistency", then it may become a good idea to keep the 'check' method, as a private member, and then just invoke it at the end of each relevant public method. That will avoid code duplication.
In your case, you could create a class with a label and a button as members, or a subclass of button with an added label member (and other similar combinations, but those two are most likely to make sense). You give it the method for the 'consistency check': if the contained label has zero value, disable the contained button. Then you iterate over a collection of those classes, telling each to check for consistency.
Except that now we can invoke another design rule that's more OOP specific: instead of having an explicit 'consistency check' style method, the object should be responsible for keeping itself *always* in a 'consistent' state. I.e., this code really belongs in some other function that sets or changes the label value. We accept a value, set the label accordingly, and also enable or disable the button according to whether the value is zero.
If there turn out to be several methods that could affect the object "consistency", then it may become a good idea to keep the 'check' method, as a private member, and then just invoke it at the end of each relevant public method. That will avoid code duplication.
Just to add to what Zahlman said, while the Item property allows you to access members by index, it really depends on the two collections being mantained correctly, which at some point they probably won't be.
I'd suggest creating a winforms control that has a label and a button and adding those to a single collection instead.
I'd suggest creating a winforms control that has a label and a button and adding those to a single collection instead.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
