Controls Collection Order of Controls 1

[Elena]

Hi,

I want to iterate through all the controls on a form and do some testing based on what type of control it is and what information it contains. I can do this without any problems, but I want to do it in a particular order. If I use the For Each....Next scenario, I have no control over what order the controls are looked at.

Is there a way I can set the order of the controls at design time so that the iteration will go in the order I want?

Thanks,

Elena

 

[TheVampire]

I thought when the "For Each" loop was used to go through controls on a form, that it's order was based on the TabIndex that is set at design time. Is this not the case?

Robert

 

[MichaelRed]

AFAIK, the order would be the order of the instantiation of hte controls. The only way to do it differently would be to build an array (collection, list, ...) of the controls and iterate through them in the defined order.

You can, of course, build such a 'list' by the original for list, picking put the property/attribute and then organizing/sorting the controls acording to your criteria. Ysing the control name is probably a poor choice, as it may necessitate a manual correction (or an omission / error) each time the form is modified. A possability would be to use the Tag property of each control to store the sort info, then collect the tag and controlname property in the array. Use that (sorted) array / collection for your test run.


Without learning more than I probably should know about your plan, it is difficult to truly understand why there should be an 'order' to processing the controls. Generally, the differnce in processing is acording to the type, which is readily available, although I could at least see some logic to the use of the tab order.

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over

 

[CCLINT]

No, it's based on the order of creation as in the *.frm file.

If you open this file with a text editor, then you can change the order of creation. But, no guarentee that it will remain the save when the project is save again. [/b][/i][/u]_{*******************************************************
General remarks:
If this post contains any suggestions for the use or distribution of code, components or files of any sort, it is still your responsibility to assure that you have the proper license and distribution rights to do so!}

 

[TheVampire]

Well, after a little experiment, I found out this.

The collection goes backwards through the controls as they were placed on the form. It appears to do all controls that have a windows handle first, followed by all of the controls that don't have a handle ( like image, line, label ).

Robert

 

[CCLINT]

Good idea using the Tag property MichaelRed. I already had a similar plan to the one below, but the Tag property saves a couple of steps:

Dim i As Integer
For i = 1 to Me.Controls.Count
For Each c2 in Me.Controls
If c.Tag = i then
'Do something
End If
Next c2
Next i [/b][/i][/u]_{*******************************************************
General remarks:
If this post contains any suggestions for the use or distribution of code, components or files of any sort, it is still your responsibility to assure that you have the proper license and distribution rights to do so!}

 

[MichaelRed]

CCLINT,

Yes, perhaps, but your usage STILL requires the tag property to be manually maintained. I was thinking more along the lines of some approach which would process all controls. Perhaps a sub-set would actually have the ordering information in the Tag, but the remainder would default to still being processed - just NOT in the proscribed order. Alas, it STILL needs the manual maintenance to maintain the correct order - but at least by processing all, it could act as a reminder to correct the new/changed controls to be placed correctly in the ordering.

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over

 

[Elena]

Thanks for all the input, guys. All very good ideas. I have one question. I see mention of manually maintaining the order. If I put all the tags in at design time, what would there be to maintain?

Let me explain more about what I am doing.

I am writing a program to test log files for pass/fail. There are many logs and they are divided into subgroups by the OS they were tested on and again by the system configuration. On my form, I have the user browse to the location for the set of logs for each OS and system configuration. I then use the For Each...Next to go through the controls and determine first, if the control is a text box, second if the control is visible (not all configurations apply everytime,so there could be some that are invisible). Then, I use the name of the control in a Select Case statement to test each OS/System Config's set of logs. What I want to do is start with one OS, say XP, and do all the configs for XP, then Windows 2000, and so on.

Right now, I am getting the last config for Millennium as the first control it sees, so I need to be able to change that.

I will try the suggestions here, starting with the .frm file. That seems to be the easiest route. Most of the programming is already done, so I would not be wanting to go back and redo a whole lot of code.

Thanks for the input. Please let me know if there is any other suggestions.

Elena

 

[CajunCenturion]

Another approach that you can use, although I'm not sure about the memory implications, but make every control a control array. Set the index number of the control to represent the sort order.

You can create a textbox array with 3 elements and set the index values to 5, 12 and 17. Create a checkbox array of 3 elements and set their index values to 4, 8, and 9 for example. Then, using a slight modification to CCLINT loop, you check the Index property rather than the tag property. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[Elena]

OK,

Editing the order in the .frm file worked, but I am concerned about the statement you made - "But, no guarentee that it will remain the save when the project is save again."

Can you elaborate on that?

Thanks,

Elena

 

[CajunCenturion]

What CCLINT means by that is that whenever you make a change to the project, the .frm file is rewritten, and there is no guarantee that the control definition section of the .frm file will be written back in the same order. If you use the Control Array and Index method, then this will not be an issue. Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[MichaelRed]

When you enter the Id "at design time", you are -then and there- doing the (inital) data entry of an "ordering". As your app evolves, you may (will) do standard data processes (add/edit/delete) for the various objects and collections. The files you work with will change. Your goals will change. The organization (of just about everything) will change. Your desig (app) will change to accomodate the other changes and needs. At EACH step, you would need to review, and potentially process the Id system (add/edit/delete). The norm for humanity is to be the weakest link in the chain, so the anticipation is that 'you' will forget to do some part of the update and become the primary failure mechanism.

What I was (am?) attempting to introduce into the (thgought) process is simply that including the necessary identification mechanism in some other part of the overall activity may remove some of the probability of the failure.

If, for instance, a SPECIFIC naming convention for the controls included information for the id sequencing, you could then read the controls collection at 'run time' and devlope the necessary indicies from that mechanism.

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over