And here's an illustration with your own test code, which helps take a good bit of the mystery out of what's happening:
The reason things looked so scrambled before, is you were running data from (1 to 5, 1 to 5), in an array dimensioned (0 to 5, 0 to 5), cutting things off and messing up the index where no data was even availabe to look at.
Like this, you can see that the initial data starts out as you suggest:
1, 2, 3, 4, 5, 6
7, 8,......
13, 14,......
19, 20......
25, 26.......
31, 32......
And since data is stored DOWN to RIGHT, when you resize, you see:
1
7
13
19
25
31
(see that pattern continue as the data is moved as you'd expect to be?) But we now have 5 more rows of data, so we just keep copying:
1
7
13
19
25
31
2
8
14
20
26
32
And then we copy up onto the next column, since we filled the first column now:
1 , 32
7 , 3
13, 9
19 .....
25.
31.
2.
8
14
20
26
32
It's not "scrambling the data", as it appears at first, with your example. It's just copying it directly in one chunk of memory, and the indexes are aligning and matching up anymore.
The *only* time REDIM _PRESERVE works properly for you us when you REDIM on the *RIGHTMOST* index. Redimming anywhere else will cause your data to be misaligned with your new index structure.
And if you're curious why your original data looked the way it did, See if this makes sense once you see the whole original array and its resized version:
Code: (Select All)
REDIM SHARED Grid(5, 5)
' LoadInitialValues
FOR y = 0 TO 5
FOR x = 0 TO 5
counter = counter + 1
Grid(y, x) = counter
NEXT
NEXT
ShowArrayValues
REDIM _PRESERVE Grid(10, 10)
ShowArrayValues
END
SUB ShowArrayValues
PRINT "Array Values:": PRINT
FOR y = 0 TO UBOUND(Grid, 1)
PRINT USING "Row ## "; y,
FOR x = 0 TO UBOUND(Grid, 2)
PRINT USING " ##"; Grid(y, x);
NEXT
PRINT
NEXT
PRINT
END SUB
The reason things looked so scrambled before, is you were running data from (1 to 5, 1 to 5), in an array dimensioned (0 to 5, 0 to 5), cutting things off and messing up the index where no data was even availabe to look at.
Like this, you can see that the initial data starts out as you suggest:
1, 2, 3, 4, 5, 6
7, 8,......
13, 14,......
19, 20......
25, 26.......
31, 32......
And since data is stored DOWN to RIGHT, when you resize, you see:
1
7
13
19
25
31
(see that pattern continue as the data is moved as you'd expect to be?) But we now have 5 more rows of data, so we just keep copying:
1
7
13
19
25
31
2
8
14
20
26
32
And then we copy up onto the next column, since we filled the first column now:
1 , 32
7 , 3
13, 9
19 .....
25.
31.
2.
8
14
20
26
32
It's not "scrambling the data", as it appears at first, with your example. It's just copying it directly in one chunk of memory, and the indexes are aligning and matching up anymore.
The *only* time REDIM _PRESERVE works properly for you us when you REDIM on the *RIGHTMOST* index. Redimming anywhere else will cause your data to be misaligned with your new index structure.
And if you're curious why your original data looked the way it did, See if this makes sense once you see the whole original array and its resized version:
Code: (Select All)
Array Values:
Row 0 0 0 0 0 0 0
Row 1 0 1 2 3 4 5
Row 2 0 6 7 8 9 10
Row 3 0 11 12 13 14 15
Row 4 0 16 17 18 19 20
Row 5 0 21 22 23 24 25Code: (Select All)
Array Values:
Row 0 0 21 18 15 0 0 0 0 0 0 0
Row 1 0 0 23 20 0 0 0 0 0 0 0
Row 2 0 2 0 25 0 0 0 0 0 0 0
Row 3 0 7 4 0 0 0 0 0 0 0 0
Row 4 0 12 9 0 0 0 0 0 0 0 0
Row 5 0 17 14 0 0 0 0 0 0 0 0
Row 6 0 22 19 0 0 0 0 0 0 0 0
Row 7 1 0 24 0 0 0 0 0 0 0 0
Row 8 6 3 0 0 0 0 0 0 0 0 0
Row 9 11 8 5 0 0 0 0 0 0 0 0
Row 10 16 13 10 0 0 0 0 0 0 0 0