Error 16: Expression too Complex - problem with Dynamic Array
I have a dynamic array which isn't necessarily 'Dimmed' to start with (so it's just empty) and when I come to assign a value to an element I test if it's Dimmed using the standard method (first shown by OnError on these forums I believe). The trouble is, if I check if the array is dimmed and then assign a value to it if it isn't empty I get Runtime Error 16: Expression too complex.
The code below demonstrates this pretty well - just paste it into a Form_Load event and run it:
'This snippet is written to illustrate a problem with
'testing if an array is dimensioned or not.
'On Windows XP Home SP2 with VB6 (SP6) this gives an
'"Expression is too complex" error (Error 16) - not tested
'on any other systems.
'Create a couple of variables
Dim Val1 As Single, Val2 As Single
'Create an array
Dim MyArray() As Single
'Put an element in the array
'The rest of this code could be in some other function
'somewhere, but it still throughs up the error anyway.
'Assign some values to the variables
Val1 = 46: Val2 = 2
If (Not MyArray) = -1 Then 'check if the array has been dimmed
'The array is empty - do nothing
'Assign a value to the zero element of the array
MyArray(0) = Val1 / Val2
This problem has kind of been mentioned in other threads (such as this one) but never pinned down like this. Does anyone have any words of wisdom on what's causing this problem and how to solve it?
Tried this out myself... it seems that the (Not Array) method does something that VB doesn't expect.
It looks like getting a pointer in this way modifies the pointer somewhat, and gets it pointing somewhere it shouldn't.
By adding another Not I got some odd results like the same runtime error BEFORE the array was Redimmed, or even used!
Unless you have access to the VB source code, you can only guess at why this happens. Just don't use this method if it affects you.
Rather use the standard LBound/UBound test with error handling.
VB is officially a closed development environment. VB does not officially support pointers. You can get them, but you're on your own once you do.
There's all kinds of stuff like subclassing, or COM, that VB just doesn't handle fluidly, because VB is getting up to all sorts of background shena****ns that you never see, or can hope to understand.
We often have to come up with workarounds without actually understanding why the workaround works.
The truth is hidden somewhere inside msvbvm60.dll.
Unlike C++, java, etc., you can't tell VB to "dumb down".
Like sands through the hourglass, so are the days of our lives..