ForEach - controls - order...?

[JamesB]

Hi,
I have a foreach... on a bunch of checkboxes in a groupbox.
What order will this work in? I have to leave my processing on two of the
checkboxes until after the others... is there any way to determine/alter the
order it works in?

 

[Marina Levit[MVP]]

I would expect in the order the controls were added to the groupbox.

 

[Peter Duniho]

I would expect in the order the controls were added to the groupbox.

Me too. Seems likely since that also defines tab order (until someone
comes along and changes the tab order).

However, I would suggest that depending on this would not be a good idea.
Since the collection is essentially unordered, it would be unwise to rely
on some external side-effect such as the order in which controls are added
to the form. It is far too easy for this kind of code to break.

I would recommend instead imposing some order on the controls by
maintaining a separate list of the controls that *is* ordered and
deterministic in a documented way. You might name the controls with a
number somewhere and use the number for the sort key (still relies on the
way the controls are edited in the designer, but hopefully in a more
self-documenting way), or make a separate table mapping an index to each
control, or even just hard-code the index and controls somewhere in an
initialization function (would be my least-preferred method, but it'd
still be better than depending on the order in which controls are added to
the form).

One could certainly rely on the tab-order matching the enumeration order,
but that seems to me to be about the most fragile way to accomplish the
goal.

Pete

 

[JamesB]

Me too. Seems likely since that also defines tab order (until someone
comes along and changes the tab order).

However, I would suggest that depending on this would not be a good idea.
Since the collection is essentially unordered, it would be unwise to rely
on some external side-effect such as the order in which controls are added
to the form. It is far too easy for this kind of code to break.

I would recommend instead imposing some order on the controls by
maintaining a separate list of the controls that *is* ordered and
deterministic in a documented way. You might name the controls with a
number somewhere and use the number for the sort key (still relies on the
way the controls are edited in the designer, but hopefully in a more
self-documenting way), or make a separate table mapping an index to each
control, or even just hard-code the index and controls somewhere in an
initialization function (would be my least-preferred method, but it'd
still be better than depending on the order in which controls are added to
the form).

One could certainly rely on the tab-order matching the enumeration order,
but that seems to me to be about the most fragile way to accomplish the
goal.

Pete

Agreed - especially if I subsequently add or remove controls.

As it turned out, only two of them were important, needing to be processed
in a certain order once all the others were, so i've basically skipped the
relevant two, and manually call my processing method on them afterwards.

I agree some sort of defined mapping would be a more elegant solution
though!