Re passing a long, the C API (1997) doesn't distinguish doubles from longs so you have to pass in a double and static_cast it to a long. Regarding the new one, I don't know. You could easily add long as a user defined type that is cast from doubles via static_cast. Re a chm file, I'd only do this if it could be automated so much that it was trivial to use.

QuoteOriginally posted by: AlexesDadDon't do that. It won't work.i'll take that as a challenge...following mj's sage advice the below seems to work fine though: running the "test" function in VBA prints "3", and nothing falls over. The difficult bits with all this stuff are (1) remembering to declare your callback functions as __stdcall, (2) remembering that C++ and VBA behave differently with respect to passing arguments by copy/value, so you have to declare VBA args as ByRef or c++ ones as pointers, and (3) fiddling round with SAFEARRAYs, BSTRs and VBA Types vs c++ structs, when you want to pass more complicated arguments than just doubles.I've never experimented with xlUDF; i'll probably have a play with that also... c++ xlw functiondouble TestCallBack(double fptr, double x){ typedef double (__stdcall *VBFunction) (double x); VBFunction f(reinterpret_cast<VBFunction>(static_cast<long>(fptr))); return f(x+1.0);}VBA codePublic Sub test() Debug.Print Run("TestCallback", AddressOf callbackfunc, 1)End SubFunction callbackfunc(ByVal x As Double) As Double callbackfunc = x + 1End Function

QuoteOriginally posted by: samyonezQuoteOriginally posted by: AlexesDadDon't do that. It won't work.i'll take that as a challenge...following mj's sage advice the below seems to work fine though: running the "test" function in VBA prints "3", and nothing falls over. The difficult bits with all this stuff are (1) remembering to declare your callback functions as __stdcall, (2) remembering that C++ and VBA behave differently with respect to passing arguments by copy/value, so you have to declare VBA args as ByRef or c++ ones as pointers, and (3) fiddling round with SAFEARRAYs, BSTRs and VBA Types vs c++ structs, when you want to pass more complicated arguments than just doubles.I've never experimented with xlUDF; i'll probably have a play with that also... As I recall, the problem was that once I called the VBA function there was no guarantee of control being passed back to my C++ function in an orderly way after the VBA function had finished executing. As I was attempting to fit the function implemented in VBA by an iterative method, I was calling the VBA function multiple times expecting control to be passed back to my C++ function after each execution and I think I had problems. Of course I may have to stand corrected on this and may have my wires crossed, it's been a while.Best of Luck A'sD

This whole discussion does raise a more general question. What do people want from xlw?What I wanted was an easy way of exposing C++ functions to EXCEL, this is what xlw is now good at it since I have pushed it in that direction. And A'sD has done the same for C#. However from time to time, people asking about doing other things?egexposing objects to EXCELusing C++ to control EXCELpythonopen office plug insSo what do you want from it? if you don't like xlw (and I know some don't) why don't you like it? (Please no comments about 3rd party libraries.)

Integration with STL, boost and OpenMP libraries.I would not be in favour of C++ wrappers for C# interfacing; go native.

QuoteOriginally posted by: CuchulainnIntegration with STL, boost and OpenMP libraries.I am not sure what you mean by this. XLW is essentially a Boiler-Plate software solution and as such, aims to be as thin as possible whilst striving for easability/triviality in the developer experience. Moreover XLW should be seen as a tool to help the developer write the user-end application and not as the user-end application itself. Hence, whether the user-end app is integrated with Boost, OpenMP etc, it should be the decision of the developer using XLW not imposed by the developer developing XLW.I, personally, would of course encourage developers using XLW to build Excel UDF libraries to make as much use of Boost as possible but I would refrain from forcing them to do so by imposing it's integration via XLW.QuoteOriginally posted by: CuchulainnI would not be in favour of C++ wrappers for C# interfacing; go native.Why not ?

xlw supports boost in the sense that you can pass matrices and arrays in to boost classes.

QuoteOriginally posted by: AlexesDadQuoteOriginally posted by: CuchulainnI would not be in favour of C++ wrappers for C# interfacing; go native.Why not ?C# can do the job without C++. MS does the plumbing, so what reinvent the wheel?It's like mixing your drinks...

QuoteOriginally posted by: CuchulainnC# can do the job without C++. MS does the plumbing I beg to differ. I am of the opinion that "no it can't" and "no they don't"The Excel 97 & 2007 SDKs exhibit only C APIsFrom MSDNQuoteThe Microsoft Office Excel 2007 XLL Software Development Kit (SDK) is designed to help you understand the concepts and technologies that relate to creating DLL add-ins for Excel 2007 that use the C API. The C API enables DLLs to tightly integrate with Excel 2007 and access its internal functionality. These DLL add-ins are known as XLLs. hence the need for using C++ & C++/CLI to open up the C SDK to C# developers. QuoteOriginally posted by: Cuchulainnso what reinvent the wheel?I tend to think of it as extending the wheel so that more then one vehicle can utilize it.QuoteOriginally posted by: CuchulainnIt's like mixing your drinks.....hmm I think a better analogy is to say it's like discovering you can get more from grapes than just grape juice, like wine

Quotethe need for using C++ & C++/CLI to open up the C SDK to C# developers. Good point.But COM is at the heart of Windows, and C# uses this API.

QuoteOriginally posted by: CuchulainnC# uses this API.I think it's fairer to say that C# developers tend to use this API. With XLW we have tried to open up the Excel XLL SDK API to C# developers, the power of which, upto now, has only been at the disposal of C/C++ developers. In doing so, the dedicated Excel API for writing UDF libraries is now accessible to non C/C++ developers. Of course XLW isn't the only option for non-C/C++ XLLs, there is also ExcelDNA.

If you are really interested in C++ based approach, one tool worth exploring is auto-XLL generation. i.e. given a C++ dll, the tool can generate a XLL wrapper for as much functions as possible (and, ideally, leave a hook for those cannot be auto converted).One practical pain for many quants/quant dev is to wrap existing analytic libraries in order to expose its functionality to Excel. This usually involves mechanic creation lots of proxy functions either in VBA or a C++ wrapper. e.g. for a BS(....) function in a quant library, you need to create a corresponding BS(..) in VBA or C++ wrapper. This exercise is totally boring and low value add.

QuoteOriginally posted by: zhouxingIf you are really interested in C++ based approachI AM , I AM !!QuoteOriginally posted by: zhouxingIf you are really interested in C++ based approach one tool worth exploring is auto-XLL generation. i.e. given a C++ dll, the tool can generate a XLL wrapper for as much functions as possible (and, ideally, leave a hook for those cannot be auto converted).So what you're saying is that if I want to write C/C++ functions for Excel then I should write them in a DLL and use a third party tool to try to generate XLL wrappers from the resulting binary, INSTEAD of writing my C/C++ functions directly for Excel and just having the XLL wrappers generated automatically at compile time as part of the compilation process ?WOW, zhouxing ! The extent of your great wisdom on the subject of Excel UDF's never ceases to amaze me ! You truly have a 'unique' vision of Excel UDF development. QuoteOriginally posted by: zhouxingOne practical pain for many quants/quant dev is to wrap existing analytic libraries in order to expose its functionality to Excel. This usually involves mechanic creation lots of proxy functions either in VBA or a C++ wrapper. e.g. for a BS(....) function in a quant library, you need to create a corresponding BS(..) in VBA or C++ wrapper. This exercise is totally boring and low value add.Hmmmm I see what you mean. This awful convoluted process is illustrated hereOh, how rude of me, just going in and responding to your post. Who's question or query were you addressing anyway ?Edit: Corrected the link. Thanks to zhouxing for pointing this out

AD - you misunderstood. It's not "write them in a DLL". It's existing DLLs. Almost all banks will have already written quant libraries (primarily in C++). The question is what's the easiest way to expose some of these functions to Excel. BTW, cannot see your Youtube link in work.

Actually you don't reference explicitly exisiting DLLs until the second paragraph. Your first paragraph begins with "If you are really interested in C++ based approach one tool worth exploring is auto-XLL generation."and then you immediately follow with "i.e. given a C++ dll"I therefore believe (especially with the use of "i.e.") that there is an implication that the C++ based approach necessarily requires a priori a C++ DLL.