1. Code so that it works
2. Code so that it’s pretty
3. Code so that it’s fast
– end quote –

Glad to see “it’s fast” is last. {grin}

I find it both sad and hilarious that there are so many who want to make their solution “fast.” The result often is that that they get the wrong result very, very fast. {vbg}

If by “pretty” you mean readable and maintainable, you will find that if you make it #1, the “it works” will follow naturally. So,

1. Invest the time to find / create a good algorithm
2. Implement it in a readable and maintainable manner
3. If the performance is not acceptable
… 3.1 See if tweaking the existing implementation does the job w/o sacrificing too much of #2.
… 3.2 If not, try and find a better algorithm
… 3.3 If none can be found, stick with 3.1

1. Code so that it works
2. Code so that it’s pretty
3. Code so that it’s fast

At #3, I put a timer on the code and work on the biggest time sinks until it’s fast enough. Expensive though it may be, I’ve *never* had to change to block redims to improve performance. It’s not that I’m not a fan (although that’s exactly what I said), I’m just not a fan of coding for speed before measuring. If I ever work with a large enough data set, individual redims may make the cut, although it’s as likely I will find a faster way to compute the upper bound outside of the loop.

I was considering such an approach as I am potentially dealing with a fair amount of data and want to know what people thought of this. Is it the extra work(code) or is it something else?

Great thread.

I thought it might have something to do with the Perfmon utility, which is installed on the old computer and not the new one, but disabling this and removing the reference to it seems to make no difference.

I always thought one had to Dim a variable before it could be ReDimmed, but a quick test in 2003 showed that I was wrong (which happens so rarely!).

I have heard of a number of unexpected VBA changes in 2007, which are pretty much the same as this: minor but annoying.

I have the following code:

Option explicit
Function Elastic( …
‘ Dim statements with no reference to RLayers()

…

ReDim RLayers(1 To NumReo + 1, 1 To 18)

…

End Function

On my old computer this works without complaint.

On my new computer with the same Excel (2007) and the same OS (Vista) I get the compile error:

“Can’t find project or library”

I can make the problem go away by inserting a Dim statement (Dim RLayers() as double), which obviously I should have done in the first place, but I’m curious as to why I’m getting this different behaviour.

I can’t see any differences in the VBA references list in the two computers.

Any other ideas what might cause the difference in behaviour?

If you are using arrays to create lists of data so you may paste the entire list into an Excel spreadsheet using a single paste operation, then it’s generally a matter of transposing the array, using ReDim Preserve, adding your extra information, and then transposing it back to the way it was.

I’ve seen that in the help before, but I’ve never seen where it causes a problem.

I’ve always been able to do this:

Dim arrTest() As Long

ReDim arrTest(1)
MsgBox “UBound(arrTest) = ” & UBound(arrTest)
Procedure1 arrTest
MsgBox “UBound(arrTest) = ” & UBound(arrTest)

Sub Procedure1(ByRef arr() As Long)
ReDim arr(10)
MsgBox “UBound(arrTest) = ” & UBound(arr), , “Procedure1?
End Sub

Could someone please explain when this wouldn’t work? Or why the help file says that, even though it is apparently not true?

If you use the Preserve keyword, you can resize only the last array dimension and you can’t change the number of dimensions at all.

Similarly, when you use Preserve, you can change the size of the array only by changing the upper bound.

If you pass an array to a procedure by reference, you can’t redimension the array within the procedure.

Jamie.

–