[RESOLVED] [2005] Order of Iteration through controls

[ZaNi]

I have been working on a project which needs to accept input from a number of textboxes. In order to minimize redundant code (and because I believe it is good practice), I have written one function that iterates through all the controls, Identifies them by their name, then adds them to the relevant list(there are three lists of textboxes, one list of comboboxes, and one list of labels). This function runs once on startup and sets some global arrays up with all the references they need for the rest of the program.

So far so good, but upon execution, the order is wrong: my first two arrays of textboxes are in the correct order, but the third is in reverse! I have made a small attempt to write a function to reverse the third list (which is not working as of this point), but it seems silly to write a function because the controls are being iterated through in the wrong order...

This leads to my question: Is there a way to alter the order in which controls as iterated through in this loop?

for each ctl as control in me.controls
  'Do stuff with control
next ctl

Any information about this would be appreciated. I have included some relevant segments of code below.

' These strings are used to identify which type of control I'm looking at
    Const boxNoOfBridgesIDString As String = "NoOfBridges"
    Const firstBridgingIDString As String = "txtBridginga"
    Const secondBridgingIDString As String = "txtBridgingb"
    Const thirdBridgingIDString As String = "txtBridgingc"
    Const labelNoIDString As String = "Label"
 
    ' Global declaration so they are accessable when I need them
    Dim boxNoOfBridges() As ComboBox
    Dim txtFirstBridge() As TextBox
    Dim txtSecondBridge() As TextBox
    Dim txtThirdBridge() As TextBox
    Dim labelNo() As Label
 
    Private Sub setupBridging()
        Dim boxcount = 0
        Dim txtfirstcount = 0
        Dim txtsecondcount = 0
        Dim txtthirdcount = 0
        Dim labelcount = 0
        For Each ctl As Control In TableBridging.Controls
            If (ctl.Name.Length > boxNoOfBridgesIDString.Length) Then
                If (ctl.Name.Substring(0, boxNoOfBridgesIDString.Length) = boxNoOfBridgesIDString) Then
                    ReDim Preserve boxNoOfBridges(boxcount)
                    boxNoOfBridges(boxcount) = ctl
                    boxcount += 1
                End If
            End If
            If (ctl.Name.Length > firstBridgingIDString.Length) Then
                If (ctl.Name.Substring(0, firstBridgingIDString.Length) = firstBridgingIDString) Then
                    ReDim Preserve txtFirstBridge(txtfirstcount)
                    txtFirstBridge(txtfirstcount) = ctl
                    txtfirstcount += 1
                    'MsgBox("Init: " + ctl.Name)
                End If
            End If
            If (ctl.Name.Length > secondBridgingIDString.Length) Then
                If (ctl.Name.Substring(0, secondBridgingIDString.Length) = secondBridgingIDString) Then
                    ReDim Preserve txtSecondBridge(txtsecondcount)
                    txtSecondBridge(txtsecondcount) = ctl
                    txtsecondcount += 1
                End If
            End If
            If (ctl.Name.Length > thirdBridgingIDString.Length) Then
                If (ctl.Name.Substring(0, thirdBridgingIDString.Length) = thirdBridgingIDString) Then
                    ReDim Preserve txtThirdBridge(txtthirdcount)
                    txtThirdBridge(txtthirdcount) = ctl
                    txtthirdcount += 1
                End If
            End If
            If (ctl.Name.Length > labelNoIDString.Length) Then
                If (ctl.Name.Substring(0, labelNoIDString.Length) = labelNoIDString) Then
                    ReDim Preserve labelNo(labelcount)
                    labelNo(labelcount) = ctl
                    labelcount += 1
                End If
            End If
        Next
 
    ' At this point, for some reason, txtThirdBridge() is in reverse
 
    End Sub

[sevenhalo]

Welcome to VBF

Well, that depends. What is "me" in this case? Me always refers to the object that it is in. If you are using a custom object that implements a sorted array list, then yeah! You have complete control of what's going on and how it's sorted.

On the ther hand, if me is reffeing to a class that's a form (or some other less defined object); you're hitting a somewhat limited area. But, not all is lost. The namespace "my" is extensible. Unfortunately, this isn't an area I'm totally proficient on (I'm in the midst of moving from the 1.1 fx to the 2.0 and not totally familiar). From what I've gathered, you can probaby do this with My, but it will take some manual work.

[ZaNi]

Me is actually a table containing all the textboxes, labels, and comboboxes.

If need be, I can try to get a function to reverse the third list of textboxes, but it seems like a waste of code and time.

I am also worried because I am doing this in a test project until I am confident that all is well, then I will be moving it to a whole new project (which I assume could change the order of iteration again).

Are we forever slaves to the order VB initalises the controls?

BTW: Thx for the welcome

[sevenhalo]

No no, we're not slaves. Just volunteered minions to MS' Fx pyramid.

I understand that Me is reffering to form controls, does that mean that the class in question implements System.Windows.forms? I'm attempting to figure out how the class is contructed first. That's going to make a huge difference on what we can eaily do here.

If you could, include the object's signature and inherits/implements so I can get a better understanding.

[ZaNi]

For Each ctl As Control In TableBridging.Controls

I was using them on the form initially but I've moved them into a standard TableLayoutPanel which I renamed.

I am not sure how to obtain the object's signature etc. If you let me know how I'll post it straight away.

[sevenhalo]

Ahh haha, ok; following you now.

TableLayoutPanel is a GUI control and should be treated thusly. Are you at all familiar with n-tier design? What you have in our hands is a presentation layer object. It's not a data object or an interface object, but... In between, an interface "state" object (think of it in the same regard as the "undo" functionality in other applications). As much as you don't want to hear it, the idea with this tier is that is combines both of the rules from the GUI layer and the business layer, but with no apparent benefit.

It is[ important though and you can't toss it out. What you need to do is make the business object for extensible to work with both UI layers. More bad news; this is one of those crafts that you can't really explain. You have to understand why it's important and drag yourself through it.

All I can tell you is, you won't be able to (and shouldn't) handle it on the TableLayoutPanel control. If you need to make an intermediary busniess object to convey some of the same data, but sorted the way you want, do it. You're in the grey and building UI data components is an articulate programming skill. I actually salute you for the effort alone.

[ZaNi]

Well thank you very much for your help

I've gotten the reversing function working for the array, so I'll use that for now. I could build a table for each array that is part of the bigger table (I assume I could anyway... I've never tried nesting tables), but I doubt it would be useful in eliminating any problems with the order the controls are iterated through.

I could always copy all the working parts and leave out the third set of textboxes, then recreate them and make sure the order is correct... And maybe if I move them into the order I want them sorted (ie switch first for last, second for second last etc) then rename them that'll work as well. I'll look into these solutions to try and get rid of the wasteful function I've got now, but worst case they are out of order and I re-sort them.

Thanks again for the help

[ZaNi]

Well that was a waste of time... I moved them all around so that the last one was first etc etc, then renamed them and had the exact same problem... There's got to be some hidden variable indicating the order controls are iterated through... except that I had the same problem after renaming them even through they should've been in the correct order...

I know its not the tab index... It might be part of the table... but that doesnt explain why its only the last column that is affected...

Well, if I can't think of anything else, I'll leave the code to reverse it in so it functions properly... I just wish I could see this damned variable that determines the order they are iterated in...

[ZaNi]

I just wanted to put an update on this in case somebody else looked for this solution.

I wrote a function that would re-sort my arrays that referenced the controls into the correct order. I made sure it was generic enough to be reused for different parts of my program (though I overloaded it with different types, because sorting labels and sorting textboxes need slight modification to the code).

I was playing with the appearence recently to sort out some other bugs, and found that if you take a label/textbox out of a table and put it back in, it changes the order the controls are referenced in that table. I tried taking them all out and putting them all back in, but the order of iteration afterwards was neither forwards nor backwards (it was something like 1,2,3,7,6,5,4,8,9,10). I gave up at this point and sent the label array to my sorting function.

I don't know if that information will help anybody, but hopefully it will. If anyone is interested, I'll post a copy of the code I used to sort the controls.

[ZaNi]

Finally!

I found out where this is actually stored.

First, if you have not got all files shown in the Solution Explorer then do that (Explain here (tip #14) down bottom of page)

After that edit Form1.Designer.vb (assuming the default name of Form1 - If you've changed it, then replace it with your form's title). You can see this file in the attached diagram.

Within that file are a number of settings regarding the setup of the form. It is autogenerated and contains a warning not to modify it, as it could cause a problem.

Within that file are all the declarations that the designer does for you so that you don't have to. The order things are created here is the order they will be iterated through (as far as I can tell), so you can re-arrange the lines to set the order correctly.

Be aware that this could cause problem for your project if you make a mistake, so it would be wise to backup anything important before trying this (especially for the first time).

Hope that helps someone

[jmcilhinney]

It's actually got nothing to do with the order in which the controls are created. Controls are iterated through following the z-order. The initial z-order is determined by the order in which the controls are added to the form's Controls collection. You don't need to edit the Designer file to change that. You simply right click a control in the designer and select "Send to Back" or "Bring to Front" and it will then be either the last or the first control that is visited when you iterate through them. If you watch the Designer file you'll see that as you do this the order of the Me.Controls.Add lines changes. You can create the controls in any order but they will be iterated through in the order you add them to the form. If you simply right-click every control on the form and select "Send to Back" each time then when you iterate through the Controls collection of the form the controls will be visited in the order you clicked them.

[ZaNi]

(*grrr* where were you a week ago?) (j/k)

Thats interesting though, cause I thought that might be it, so I tried re-arranging them to get them into something like that order (forwards or backwards would be fine, cause if it was backwards I could just do it again in reverse)

I tried taking them all out and putting them all back in, but the order of iteration afterwards was neither forwards nor backwards (it was something like 1,2,3,7,6,5,4,8,9,10).

I noticed the order was fine and dandy on forms I created from scratch (I think it went from last to first, but that doesnt matter too much), but I needed a solution for the form I was working on which already contained a number of controls most of which were tables with children controls.

All that said, I took some labels that were being problematic out of their table and put them back in from 1 - 10. I could've understood them going in forwards or reverse... I could've understood if the order didn't change... But what happened was the order went whacked to something like 1,2,3,4,8,7,6,5,9,10 ; which makes no sense at all in my mind.

For my own piece of mind, is what I said above (about the Form1.Designer.vb file) true? (I'll test it later, but I want to finish another problem first)

[jmcilhinney]

Like I said, it is the order that the controls are added to the form's Controls collection that matters. Selecting Send to Back or Bring to Front merely changes that order in the Designer file. There is no point to changing the order the controls are created. If you rearrange the order of the lines that add the controls to the form then you will change there order in the collection. That makes sense doesn't it? Just like an ArrayList, if you use a loop the items will be returned in the same order you added them. It's best to avoid touching the auto-generated code if possible though, so I'd stick with using the designer. The Designer file gets regenerated regularly so there's never any guarantee that what you do will not be lost anyway.

[ZaNi]

What you're doing there sounds like a hack though... Is there any way to define the order more explicitly (ie instead of sending them to the back in the order you want them to be iterated through)?

[jmcilhinney]

There's no way to do it at design time but there is at run time. Every control has BringToFront and SendToBack methods that you can call explicitly at run time. These are the methods that get called by the IDE when you select the corresponding menu items. At run time you can also call the SetChildIndex method of the form's Controls collection. There is no way to access that method at design time. You could probably write a VS macro to do the job if you are keen. The IDE offers a great deal of extensibility but the vast majority of people will never use those features. It's just b*tch and moan when the IDE doesn't do everything already, just like me.

[ZaNi]

lol. B*tch B*tch Moan Moan...

I was mainly curious, and its good to hear that it was difficult and not just me (I spent a very long time looking, and if somebody came along and said "all you needed to do was click here", it might have been a little frustrating).

Either way, thank you very muchly for all your help. I think i've got the knowledge I need to handle the problem now (I think sticking with the sorting is a good idea... I might put it on all of them so that if something gets mucked up it'll sort itself anyway - it seems efficient enough given that it runs once per program execution).