Control Arrays and element zero 1

[Motor11]

Hi Folks,

I have a program with a single control array element (a command button) and other elements of the array that are created dynamically with the Load command.

I am seeing some unusual behavior with element zero. It seems that sometimes this element exist and sometimes it doesn't. I can always see the button, but occasionally get an "Error 340 (Control array element '0' does not exist)".

This behavior seems strange. The button exists. I can click the button and see an index of '0' when I watch the click event execute. The program fails when I try to execute the setfocus method on the button with index zero. A watch of the control array reveals that an element with index zero is only sometimes in the array... strange. I haven't removed the button through code (and it is still visible).

Any ideas?
Ryan

 

[JCruz063]

Ryan,
I used to experience the same problem with a control array of mine but in my case the error used to occur with any of the controls (not only with the control at index 0). Also, in my case, I didn't load any elements at run time and the controls that appeared to be missing were those that were created at design-time (bizarre, I know).

In any case, I discovered what was causing the problem. In the form where the control array was, I created a form-level variable of type TextBox (I have a control array of TexBoxes, not Buttons). At various parts of my code, I have statements like this:

[tt]Set fTextBox = theControlArray(index)[/tt]

fTextBox is the form-level variable and theControlArray is the control array of text boxes (duh!). In the DoubleClick event of each of my TextBox controls, I would have the line
Set fTextBox = theControlArray(Index) because I needed to know what the last double-clicked TextBox was. Of course, I could have accomplished this a number of other ways but this was a couple of years back when I used to think a lot less than now .

Anyways, as bizarre as it may look, I discovered that when the user exited the form without exiting the application, the textbox referenced in fTextBox was destroyed. When the user came back to the form (my application has several forms), the last text box that I had stored in fTextBox would be missing, and I would get that "Control Array Element x does not exist" error. Strange, very strange!!!

To solve the problem, all I did was add the following statement in the QueryUnload event of my form.

[tt]Set fTextBox = Nothing[/tt]

Apparently, not doing this makes Visual Basic kill the acutal control stored in fTextBox when the form was unloaded.

One last thing: I noticed this error only in a Windows 98 computer. I bought a new machine with Windows XP on it and tried removing the Set fTextBox = Nothing statement and I didn't see the problem. With the Win98 machine, I was able to replicate the problem whenever I wanted.

Hope this sheds some light!

JC

_________________________________________________
To get the best response to a question, read faq222-2244.

 

[Motor11]

Thanks for the response JC,

It sure looks like I have rediscovered the feature (bug!) you're alluding to in your post. Yeah, I am using a set command to store the index of the selected button because I need to pass it to another form. And yeah, the form unload occurs (as designed) shortly after I set this variable. Hmmmm?

So now I've got something to try. It's going to take a little work on my part because this variable is a global and is used elsewhere, so setting it to 'Nothing' is going to be difficult. I may be able to work around it.

Well, I'm glad someone else has seen this. It is such a strange behavior that it has me completely confused. For example:

The command button is removed from the array after the program executes this line of code (in the mousedown event):
If Button = vbRightButton Then

How strange is that? It seemingly has nothing to do with the command button (Button refers to the mouse button in this code). I am perplexed to say the least.

Thanks for the advice, I'm off to give it a try.

Ryan

 

[Motor11]

JC,

That did it. Turns out I could safely clear the variable (the one that holds the index of the clicked button) in the QueryUnload event and I did so. Voila! No more "Error 340".

Now if I only knew why this works. Thanks for the help.

Best regards,
Ryan

 

[JCruz063]

Ryan,
Very, very strange!!!

As to why it may happen.... the only thing I could think of is that this is a bug in the COM architecture which Visual Basic uses under the curtains. The fact that the form-level or global variable goes out of scope without you setting it to Nothing may confuse COM to the point that it may think that the object to which the variable refers to is no longer needed. When this happens, [I assume that] COM decides that the object should be disposed of and destroyes the actual object. Alas, such object should not be destroyed and that's why we get "Runtime Error 340". Well, as we've discovered, setting the variable to Nothing before it goes out of scope clears out the confusion.

Of course, this is just my opinion.

JC

_________________________________________________
To get the best response to a question, read faq222-2244.

 

[Motor11]

JC,

One more comment for the sake of completness of this thread (you never know who looks these things up later).

My variable that held the index value was a globally declared integer. It shouldn't have referenced my command button object at all -should just have stored the value of the index. Perhaps we have a byval vs. byref issue (and I always get those keywords mixed-up).

And being an integer with a global scope, I had to set my variable to zero (as opposed to setting it to Nothing):

Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
currentbutton = 0
End Sub

This worked like a charm and I haven't seen the error since. It is, as you said, very odd behavior though.

Thanks again for putting me on the right track.
Ryan

 

[JCruz063]

Ryan but if you're just resetting an integer to zero, all my nice professional-looking comments about the faulty COM architecture go out the window ! I would not expect that setting an integer to 0 would cause this strange behavior. But then again, this is Windows!

JC

_________________________________________________
To get the best response to a question, read faq222-2244.