Excel Xll C add-in xl_array FP coerce

[gabymour]

I was trying to obtain data from Excel via the FP array (xl_array) but was
completly unsuccesful.
I don't want to register the function just want to access it from VBA
Here is the declaration in VBA
Declare Sub arrayfn Lib "D:\Dev\XLAI\Debug\XLAI.dll" (ByRef v() As Double)
Here is the code of the VBA function that call the Excell

Sub tst()
Dim zz(1 To 6) As Double
zz(1) = 1.2
zz(2) = 2.3
zz(3) = 3.4
zz(4) = 4.5
zz(5) = -10.2
zz(6) = -10.2
Call arrayfn(zz)
End Sub

I want to receive this as an FP array (xl_array) in C/C++
here is the declaration of the c function

void XLL_CALL arrayfn(xl_array* pa)
{
double v;
c = pa->columns;
r = pa->rows;
v = pa->array[0];
}

But what i am recieving is a corrupted array. I tried the Variant approach
and i received succefully a SAFEARRAY. But it is cumbersome. I want to use
the xl_array. WHat is happening here???!!!

Another question is about coerce. Is there a way to read a range of cells
from Excel in C/C++ without using coerce? I Tried coerce on the following
data on a worksheet

1.10E+00 1.20E+00 1.30E+00
2.10E+00 2.20E+00 2.30E+00
3.10E+00 3.20E+00 3.30E+00

excel is giving the values but instead of 1.10 i am getting 1.10000001 and
instead of let's say 2.3 iam getting 2.29999999

It is clear that excel is reinterpreting the values and recalculating. How
can i prevent that or is thee another unction to read data from excel??

Thanks

[Steve Dalton at dot]

You can't get a VBA array as an xl_array (FP) into your DLL. The al_array
(FP) data type is a C API data type and you can opnly get those via
functions registered with Excel as XLL add-in functions. (You could use the
XLM macro language to do this). VBA passes OLE SAFEARRAYs to DLLs and you
have to interpret them as such. You could make the conversion less tedious
by writing a simple conversion function that you call on your safe array
arguments.

As to the rounding issue, I have seen this many times, but do not have an
adequate explanation. The 8-byte double within Excel is not, as I
understand it, fully IEEE compliant and this may be the problem, or it may
be that there's an implicit conversion to/from 4-byte floating point. In
practice, the 1e-8 (?) error is quite small. If you are testing for
equality this will clearly cause you problems, but you might be able to get
away with testing for equality within that margin of error.

Regards

Steve Dalton

"gabymour" <u58769@uwe> wrote in message news:a50d2f30e336e@uwe...