Hi all,I'm looking to learn XLW since this seems like an excellent tool. However, during my playing around I get some curious results: I have implemented a simple function returning 3.14, and wanted to do the same using a class method. This last approach will yield 2,7E+308..Are there restrictions using classes and XLW? Which approach should I use? The attached code is wrapped just like ordinary functions, by creating an object and then calling the method.Thanks!Stale

Hi Stale,QuoteOriginally posted by: StaleAre there restrictions using classes and XLW? Which approach should I use? The attached code is wrapped just like ordinary functions, by creating an object and then calling the method.XLW's functionality is procedural and the only way to return the value from a member function of a class is to implement the XLW addin function as a wrapper which invokes the member function on some existing or temporary object and returns the value from that. You say that you have done exactly that, so there must be a problem with the implementation, please post the code of your addin function.Regards,Eric

QuoteOriginally posted by: StaleHi all,I'm looking to learn XLW since this seems like an excellent tool. However, during my playing around I get some curious results: I have implemented a simple function returning 3.14, and wanted to do the same using a class method. This last approach will yield 2,7E+308..Are there restrictions using classes and XLW? Which approach should I use? The attached code is wrapped just like ordinary functions, by creating an object and then calling the method.Thanks!StaleAre you using the latest release 3.0? There you can use an "interfacegenerator" tool and it really makes things simple.Furthermore, since the add-in is a DLL, it is stateless. You still need to use function to interface with Excel while class can be used inside of the function.Hope this helps.Jeff

Thanks for your responce eehlers and jjyu.eehler, you'll see the attached code. jjuy: The interfacegenerator is really my fried! I'm trying to figure out what would be the best approach to integrating the 00 and procedural paradigms, so if you have any pointers in that respect I would be grateful.Thanks, Stale

Hi Stale,QuoteOriginally posted by: StaleThanks for your responce eehlers and jjyu.eehler, you'll see the attached code. jjuy: The interfacegenerator is really my fried! I'm trying to figure out what would be the best approach to integrating the 00 and procedural paradigms, so if you have any pointers in that respect I would be grateful.Thanks, StaleThe implementation of your returnClassPI() function looks OK, so perhaps the problem lies with the way in which that function was registered with Excel, please post the relevant code. Functions may be registered using either XLFunctionRegistrationHelper (the correct way) or XlfFuncDesc (deprecated).I agree with Jeff that the InterfaceGenerator is a creation of unparalleled beauty which simplifies your life immensely. But whether you write your addin functions manually or use the InterfaceGenerator to create them automatically, you are still stuck with the fact that XLW's interface is procedural with no native support for OO.ObjectHandler (http://www.objecthandler.org) supports an object oriented Excel interface. See the example application ExampleXllStatic which includes source code and demo workbooks. There's an example class Account, whose constructor, and member function Account::balance(), are exported to Excel as addin functions ohAccount() and ohAccountBalance().Regards,Eric

eehlers,Thanks for your reply. There is not much more code to post, but the problem resolved itself after a small modificatio, as you can see. ObjectHandler seems like a nice solution. I'm not quite the QuantLib (nor C++) expert, but hope to get to grips with it. Would you say OH and QuantLib is worth wile learning?Thanks again,Stale

interesting! it seems that when returning doubles we need to make sure that the double exists at the right point... we'll need to check this out.

weird, i can't reproduce the problem. What compiler and version of xlw are you using?

The original version of returnClassPI() looks OK to me and the subsequent edit shouldn't change anything.Stale mentioned an earlier implementation with no Test object which returned 3.14 and worked as expected. I see no reason why such a function should behave differently than the one shown, nor its variation.returnClassPI() returns a temporary double by value and my suspicion is that this function was registered incorrectly with Excel such that Excel expects a return value of another type - OPER*, or maybe double*. The behavior of the code is undefined which is why the result changes depending on seemingly arbitrary modifications.Stale please post whatever call to XLFunctionRegistrationHelper or XlfFuncDesc was used to register this function.Regards,EricP.S. Jeff:QuoteOriginally posted by: jjyuFurthermore, since the add-in is a DLL, it is stateless.A DLL may be stateful. For example, XLW demo project ExampleHandwritten includes function xlNbCalls() which remembers how many times it has been called.

My suggestion is to bring up the debugger to see what is going on.I did this in Visual Studio environment:1. bring up Excel and install the add-in;2. Set the break point inside your code, attach to Excel from VS;3. enter the function in excel, it should stop at the break point;eehlers, the reason I said DLL is stateless is that the global variables in DLL are on the heap. When you have multiple copies of DLL, the global variables are sharable.In order to achieve the effect of being stateful, you might have to rely on global variable? Correct me if you see it differently.thx.Jeff

Hi Jeff,QuoteOriginally posted by: jjyuMy suggestion is to bring up the debugger to see what is going on.There is a very small and very relevant piece of code which we have still yet to see, wouldn't it make sense to have a quick look at that before starting the debugger? Mark tried without success to replicate Stale's error and I suspect it's because Mark's call to XLFunctionRegistrationHelper is correct and Stale's isn't.QuoteI did this in Visual Studio environment:1. bring up Excel and install the add-in;2. Set the break point inside your code, attach to Excel from VS;3. enter the function in excel, it should stop at the break point;Here's an alternative approach which can be more convenient:- Open the addin project in Visual Studio- Under Project | Settings | Debug, under "Executable for debug session", enter the path to Excel- Now when you hit F5, Visual Studio starts Excel, loads the addin, and attaches the debuggerQuoteeehlers, the reason I said DLL is stateless is that the global variables in DLL are on the heap. When you have multiple copies of DLL, the global variables are sharable.In order to achieve the effect of being stateful, you might have to rely on global variable? Correct me if you see it differently.You can call me Eric. ;-)A straightforward way for a DLL to retain state is for it to write that state to a static variable, whose scope need not be global. Under Windows 3.1 multiple copies of a given DLL shared writable memory but for Win32 and later that is no longer the case unless the DLL has been designed to behave that way through the use of a shared section.Regards,Eric

Eric,You are absolutely correct. Using static variable can pull the trick, just put together a small test program to confirm it.Regards,Jeff

You may also want to look at Thread Local Storage

Absolutely a right techniq to handle global variables in multi-threaded environment!Speaking of multithreaded, any thought on async operation using xlw or sdk released by Microsoft for Excel? thx.

QuoteOriginally posted by: eehlersObjectHandler (http://www.objecthandler.org) supports an object oriented Excel interface.I'm really thoroughly sick & tired of implementing stuff that I think is quite clever and then discovering that someone else has gone and done exactly the same bloody thing already and made it available, usually for free. See: boost::bind, and objectHandler, and the heated ice cream scoop that I invented when I was seven.that's all.