Nah.....nothing like that, GT. I'm expecting normal values back, like 4.3200 or whatever.

>>It's not a COM question, it's a DLL question.
>>
>>I have a DLL that's defined as:
>>
>>DECLARE integer foo IN 'foo.dll" double @value1, double @value2
>>
>>Notice that the parameters are by reference, so they must exist from the calling code.
>>
>>So I call it with:
>>
>>value1=0
>>value2=0
>>foo(@value1,@value2)
>>
>>The result is that value1 and value2 come back with a strange value such as 2.63E-308.
>>
>>I have no idea what's happening. I haven't done any DLL work in a while so I'm clueless. Any ideas? It's times like this I really miss Ed Rauh.
>
>Gonz,
>
>After thinking about this, I've got a couple of ideas.
>
>First, however, there's something you should know about this SWAG.
>
>From the return value, it looks like the DLL is doing some fairly exacting mathematical calculations. It also appears that there's a difference of several orders of magnitude between the two or more values that it's calculating.
>
>I'd be suspicious of the return values under these circumstances because of the inherit problems associated with precision and the Pentium class processor. I don't know how accurate you need to be. For myself, from my experience in precision machining, it's rare that you need more than four decimal places of precision. In precision machining, that's referred to as a "tenth". IOW, 1 / 10,000ths of an inch. That's why I'm going to recommend the following.
>
>If four decimal places is sufficient, then specify the data type in the declaration as CURRENCY. Yeah, I know it isn't specified in the help file, but it compiles and should work. You'll probably also have to use the AS clause when declaring the variables. It may not matter, but that's what I'd do.
>
>If you need greater accuracy, does the ROUND() function work on the return values? I'd think not, since you've probably already tried it.
>
>Best,