No cracks about the 'bug' is sitting at the keyboard 
Try this:
<Code>
Sub Test
Dim a(0 To 9, 0 To 5) As String
a = FuncX()
End Sub
Function FuncX() as String(,)
Dim Ret(0 To 4, 0 To 5) as String
< Code to fill Ret >
FunctX = Ret
End Function
<\Code>
When you check 'a' in Test, it has been redefined as Ret: i.e. (0 to 4, 0 to 5)
No compile warning ... although I can see where it might be hard to checks this.
No Runtime error - except when I try to use 'a' with the full dimensions.
Is this a bug or is it intentional and I'm missing something (other than my mind for such poor code consistency).
Roger
Implicit ReDim - Is this a bug ?
imin83
The size of an array isn't a part of it's type definition. All the following arrays have the same exact type, and can be assigned to each other:
Dim x() as integer
dim y(500) as integer
dim z(0 to 10) as integer
What matters is the element type (integer) and the number of dimensions/jaggedness, not the length of each dimension.
Tamizhan
Thanks to both Alex and Reed.
I have a better understanding of what is going on ...
I still feel that a warning of some sort ought to be emitted.
To me this is "loose-as-a-goose" language definition (but, then again, I'm an old, old COBOL hack - so what do I know).
Reed's example bring up an interesting point: Orphan Controls
It would appear that TextBox 2 (tb2) is now unreachable.
Will GC remove it at some time
Will it 'disappear' from a form 'mysteriously' at some point
If so, I can think of a number of SERIOUS security problems this could create.
Thanks, again, to both
Roger
Speedmaster
Think about it this way, if you had that warning, it would then have to appear at every occurence of this issue:
Dim Ar(2) As Integer
Ar() = New Integer(){1, 2, 3, 4, 5, 6, 7} WARNING - Your Variable is Being Reassigned
Dim Str as String = "Foo1"
Str = "Foo2" WARNING - Your Variable is Being Reassigned
Dim Pt as Point
Pt = Me.PointToClient(Control.MousePosition) WARNING - Your Variable is Being Reassigned
You see, variables get reassigned so often that this warning would be everywhere and meaningless. It's just one of those givens that you have to know: when you say THIS = THAT you are moving a pointer and changing the instance of an object that a variable referrs to.
Takezo
The thing is that arrays are reference types (similar to classes) - an assignment thus only means that the variable now points to whatever it is that it is assigned to - the original array still exists, but your variable now points to a different object.
I understand that the concept may not be obvious, but it is certainly intended - again, you're basically replacing the array that your original variable pointed to with a brand new array. I can't verify it from my home machine, but I believe that was the behavior in vb6 also.
simonvinyl
Again, you didn't change the type. you changed the length of the memory stored under that type - when you assign a different instance of a class to a variable, that can break code that made assumptions based on which members were initialized, and what values they might have had.
Maybe a better analogy is assigning a new string to a variable - like an array, it will cause the variable to point to a different memory location, which can have a different length/values, and can break code that made assumptions on it's length. In fact, strings are pretty much arrays of char under the wraps.
bjkaledas
You analogy does not hold.
If I assign a variable to 'another' Class it is to 'another instance' of the Class. The variable remains TypeSafe in that it can only be assigned to the same Type as originally defined.
While I might change the code underlying a procedure within the Class (Type), I cannot change the Name or return Type of an existing procedure. That would break the Contract. I might extend the Contract by adding New procedures, etc., but those would not change the Contract of existing code that depended upon the Class as defined when I first used it.
This action BREAKs a contract. Even worse, there is no warning.
To use an Old Old analogy ... I send you a horse and you try to return a cow. I really don't care if they both have 4 legs. I want my horse back (or a reasonable facsimile)
IxxI
It is not a bug and is the expected (and desired) outcome of the code you’ve provided.
Note that FuncX is returning the array defined within it and it is this returned array that is being referenced by a immediately after the call to FuncX().
Does this make sense
David Cowell
Thank you or the reply. I'm pleased to see that my concern was ill-founded.
But, (in this political season) at the risk of sounding like a one-issue candidate, I still believe a warning would be appropriate.
Thank you, again
Roger
boston_sql92
I see it (but I hardly believe it).
If I reference an array in some dll to which I do not have access to the code, I can't be sure what will be returned "Error Free" --- until I attempt to use the array.
I don't dispute you are right --- I just dispute that this is the "desired" outcome.
Thanks, though
Roger
Roberto Trizio
See my response to Brendan above.
I can accept your argument (partially) that a 2 dimension array can be assigned to another 2 dimension array.
What bothers me is that MY 2 dimension array was effectively ReDim'ed behind my back.
I would suggest that if the dimensions of the assigned array are fewer, then the correct behaviour would be to 'partially' fill each corresponding dimension of the receiving array.
If the dimensions of the assigned array are greater, then the correct behaviour would be to fill the receiving array (truncating the balance)
BUT --- a warning should be issued !!!
Preferably at compile time (if possible) -- certainly at run time IMMEDIATELY when the strange assignment is made.
This was a difficult error to track down as it is behaviour I never expected.
Thanks for your help,
Roger
KingKoo
I don't think you understand variable assignment... You are getting a horse back; it's just a different color now.
Consider this:
Dim tb1 As New TextBox '-creates a new textbox object instance and points the variable tb1 to that instance
Dim tb2 As New TextBox '-creates a second new textbox object instance and points the variable tb2 to that instance
Dim testtb As TextBox '-creates a variable of the type TextBox that does not point to an instance of a TextBox object
testtb = tb1 '-points the testtb variable to the same TextBox object instance as tb1 points to
tb2 = testtb '-points the tb2 variable to the TextBox object instance referred to by both tb1 and testtb - the orignal instance pointed to by tb2 is lost
In this scenario, tb2 still points to a TextBox, but it is not the same TextBox that was created in the tb2 DIM statement - its a horse of a different color.
Your array issue is the same thing. You're changing the instance that the variable points to.
To get the behavior that you expected, you need to copy one array into the other. Then if the destination array is shorter than the source, the source will be truncated (provided you use the destination's length; otherwise an exception will be raised). If the destination is longer, it will contain empty elements at the end (provided you use the source's length; otherwise an exception will be raised). You can use an IIF statement (IIf(src.Length < dst.Length, src.Length, dst.Length)) to provide the shorter of the two array lengths to the Copy() method, ensuring the copy succeeds. Or you can trap the error and respond appropriately. It all depends on your app's requirements. But this is the way to get the results you expected.
NeTBaPb
The control will be released to GC if there are no longer any references to it.
In this case, the TextBox was created, but never added to any ControlCollection. Therefore the only reference was the tb2 variable. Once that variable no longer pointed to the instance, the object was released to GC.
If the TextBox had been added to Form.Controls then the ControlCollection would be maintaining a reference to the TextBox. In that case, even though we released the object from tb2, our Form still held a reference via it's controls collection. So we could have aquired a new pointer to that object via the collection. This behavior would prevent a control from simply disappearing from a form.