Hi AllWhen running the following code in excel :The dll used is a test dll (Excel2.dll) with only one function named gethem, which returns a varaint value of 2000.DLL developed in DELPHI 6"B" is an IEEE 8-byte floating-point number (double) and is passed by value.OS system is NT4 sp6Column 1 Column2objTest =REGISTER("Excel2","Gethem","B") =CALL(objTest) =UNREGISTER(objTest) =RETURN()Below is the result I get after running above code.objTest #VALUE! (This must be the registerID) #VALUE! (This must be the reult of the function gethem which returns 2000) #VALUE! (this must be a boolean of true) TRUE (this one is correct)Can anyone tell me why this is showing #VALUE! instead of the returned values i.e 2000.Thanksfbag

You should show us the code of your function.But I think there are 2 ways:1) you register the function with REGISTER (so check that names are may be case-sensitive, you must specify the return type, socall REGISTER("Excel2", "getthem", "RB")But you cannot return (Delphi) Variant, but LPXLOPER, defined in xlCall.h, likefunction getthem(B: Double): LPXLOPER;you should look for a translation of xlCall.h into Object Pascal2) write a wrapper in VBA, like Declare Function GetThem Lib "Excel2" (ByVal A as double) as Variantand in Delphi the function will befunction GetThem(A: Double): OLEVariant(I remember that in Delphi 3 you should use OLEVariant instead of Variant for VB compatibility (especially for strings))good luckbye

This is the code in Delphi6unit GetData;{$WARN SYMBOL_PLATFORM OFF}interfaceuses Windows, ActiveX, Classes, ComObj, Excel2_TLB, StdVcl;type TXData = class(TTypedComObject, IXData) protected function Gethem(out intRet: OleVariant): HResult; stdcall; end;implementationuses ComServ;function TXData.Gethem(out intRet: OleVariant): HResult;begin intRet:=2000;end;initialization TTypedComObjectFactory.Create(ComServer, TXData, Class_XData, ciMultiInstance, tmApartment);end.

I don't know. Your code is totally different than what I expected.If you need to call a function from Excel I think that the simplest way is to write a function in Delphi like and then a wrapper in VBA.But, why are you using the Type Library of Excel? You need it when you want to call Excel functions from Delphi. And why are you declaring a class?There is the possibility to create a COM object and then to use in into Excel or VBA but I never tried this way.You should tell us more about your goalsbyeandrea

This dll will be the CalcEngine responsible for number crunching.This is to automate a manual process of entering details and running macros against it.What this dll is will do is to bulkscan lots of transaction to existing macros.(STRESS testing)This will give existing macros the flexibility of using this DLL's function, without a big changes.I looked at using addins, which worked fine, but this will not be suitable for the funtionality required.Thanks

Ok, but I've not understand if this function will be called from a Macro of VBAa Macro of Excel4 or in a cell of a wotksheet.And, will this delphi function need to call other VBA code or it will do its own calculations and only return something?byeandrea

Thanks for the reply.I will be used in cell of a worksheet.The DLL will acept a few params and do it own calculations and returns a result.Thanks Fbag

>I will be used in cell of a worksheet.>The DLL will acept a few params and do it own calculations and returns a result.So, I prefer to write an XLL (but if you have never done it, it is a little bit complicated).You can write a standard DLL in Delphifunction MyFunc(A: Double): OLEVariant;begin if (A > 0) then Result := A else Result := "ERROR";end;and remember to export it!exports (or "export" I don't remember) MyFunc;and in VBADelcare Function MyFunc Lib "YourDLL.DLL" (ByVal A as double)and you will find the function MyFunc in the category "User Defined" in the "formula wizard"byeandrea

The two ways to write the Excel addins are:a) Use the 'Excel SDK' by writing a DLL that exports a few things like xlAutoOpen etc that registers all your functions when loaded. This is referred to as the 'C API' but the DLL can actually be written in anything. There's no doubt that it results in the fastest code. The problem is that it won't be compatible with VB/VBA without some pain. Most of the addins I've seen use this technique.b) Use VB. THis basically goes through OLE automation and results in addins that are a bit slower that (a) BUT are much easier to develop, because you can write them from WITHIN Excel / VBA. It's also possible to use C++ to write these addins, using COM, but IMHO this is MUCH messier than (a) and is still no faster!-----The other way is to wait for the release of Excel that has support for the Common Language Runtime. Basically, all the languages are compatible (C++, VB, C#,.....) and there'sno difference between (a) and (b).

HiI got it working. I reverted to a standard DLL and not a COMservice.Yes its exports.Thanks allot.Fbag