Just my two cents but you are using globals for the wrong reason. You are
better off creating the collection when it is needed than trying to keep the
collection stored globally. The code to create the collection is relatively
easy and very quick. By dynamically creating the collection when you need it
you alway get a correct list of controls.

That being said I personally almost never use global variables. About the
only time I use them is if I have an application that needs to have passwords
to access databases. I store the user info and password globally. I find
globals a real pain to debug. When they go wrong you just never know what
process messed them up.
--
HTH...

Jim Thomlinson


"atpgroups" wrote:

On 4 Jun, 13:14, "Jim Cone" wrote:

The collection still reset to nothing when I added the second combobox.
That is new to me.

I am glad it isn't just me going mad then.

In any case, I try to avoid public variables.
I will pass a collection object to other subs/function as needed an then
set it to nothing when exiting.

I don't really see that I have much option here. There is an
initialisation phase which checks the data and builds an array of OLE
links to data items in a third-party application (which in turn links
to embedded code in an engine conrtoller, which links to a dynamometer
controller...). At some future point the user can hit a second button
and start the test. In the meantime there is no thread running. I
don't want to go through the time-consuming data check and array
creation process every time, but there is no thread active to pass the
data to the second-phase code when the user presses the button. I am
not using the globals for their globality so much as for their static-
ness. Or that was the plan anyway.