...
Part of the additional generality, accepting multi-area ranges,
introduces the same bug that Harlan Grove mentioned in connection with
the rtoa function in this thread.
Correct. It seems there's no easy way to handle multiple area ranges in udfs.
I'm sure Alan's health warning implicitly includes his own MakeArray function,
which also suffers from this bug when passed multiple area ranges. I'm sure he's
tested this to see that this is so. It surely can't be the case that he believes
that just because his MakeArray udf implicitly uses only the first area of any
multiple area ranges it's passed that he would believe this relieves his udf of
the adverse consequences of this bug.
If the steps mentioned in AreasBugBypass2.xls linked in
http://www.decisionmodels.com/downloads.htm#AreasBugBypass
were followed, my udf, mkarray, would be healed. MakeArray, on the other hand,
would still be broken when passed multiple area ranges. Let A1:A20 each contain
the formula =ROW(). The formula
=MakeArray((A11:A20,A1:A10))
returns just {11,12,13,14,15,16,17,18,19,20} because MakeArray doesn't use range
object arguments directly. Instead, it only uses range arguments' .Value
properties, which effectively truncate multiple area ranges to their first area.
Since MakeArray doesn't fully process multiple area ranges, shouldn't either the
comments that serve as its documentation be ammended to document this limitation
or it should return an error to flag this as an error. Then again, maybe there's
an outside chance Alan would rewrite it so it works as claimed.