Hi all,When you call dlls (develop in VC++) from Excel/VBA, does it matter (in term of time, stability, etc...) whether you have one "big" dll or several small ones??If the best approach is the second one, there will be functions in some dll calling some other function in the other dlls, is that easy to do? is it stable? (if we have multiple user calling them...)Thanks for your help.JM

Do the DLL's have a COM wrapper?Each COM wrapper take a little time to pass through and the benefits are not that great. Keep COM out of it.As a general rule try to keep the processing out of Excel, VBA is terribly slow and I find Excel 97 'unstable' when it's dealing with DLL's - write youself a suite of programs that uses Excel only as the front end. Use VBA only as a proof of concept (and for the wrapper code!).

OTM << Can you give more discussion / detail please? The thing is I normally try to avoid mixing MSOffice with reality , but I have just been 'given the opportunity' of developing some reporting and risk management applications in Excel. Some of the app will have to fit around existing 'real' systems, however I am left with some choices regarding how to site calculation code. I don't have too much experience, but lots of bad memories. I know VB is too slow and I also don't enjoy it much, my recollection is also that XLL/DLLs are patchy and lead to fragmented code, therefore I was considering rather to use COM throughout, although only for passing data, all real action would be in C++. Any suggestions?

Hello there,I have a performance problem relating to Excel with a C++ dll. Here is my point:I compile a dll with a simple function ( such as: sum by a loop ) then I open Excel , launch a simple vb macro to call this function.I try to compare the elapsed time to run it with excel ( VB + dll ) and the direct runtime ( C++ exe ), so far it is almost the same.Now, I do the same but I change the function in my dll: I put a call to the math function log ( ie now I have a sum of log now ) .Now when I compare the excel way and the direct runtime way , I have a large gap between them: Excel is by far worse than the runtime ...If you have a clue of what's going on , I will be pleased to know it!Thx in advancePS: I have tried to cast any variables involved, it is better but I still can find this huge difference between Excel and direct runtime

bsv, I've seen you question in another thread on it's own and I am obviously being stupid but don't understand what is where! Could you enlarge and I'll answer it.Onuk,Sure - COM, the only type of dll VB6 can write, was created to allow different types of programming language to talk to each other in a common format which is platform independent. So because you can use "declare" in VB(A) code to access a a C++ dll (with some messing about with the types) try not to use COM within the calculations because it creates a overhead.I'd write everything in VBA as proof of concept (and calculations <img src="i/expressions/face-icon-small-happy.gif" border="0"&gt and migrate to VB/C++ slowley. Note that you will find that alot of the Excel 97 "Application." routines are very slow eg. percentile - we were very suprised too.VB6 and C++ v6 use the same compiler and so the differences in speed are not always very noticable if you don't use the facilities offered by the c++ language. VBA to VB usually gives a 40 times increase in speed and it is usually a cut and paste transfer BUT VBA to C++ is a rewrite opening you up to systemic errors.I'm language agnostic, OK a slight preference to C++, but I can usually persuade IT to take the VB on but it is much more difficult with C++. I want to do risk not support applications I have written. VB is quick to write esp for front ends.As a side issue I'd also suggest having look at the .net stuff C# is a halfway house between VB and C++ with the speed of C++. The SDK with compiler is free. There's a thread round here somewhere where it was discussed rather well by JamesBattle (see "what are the advantages of Visual C++ over VB?")Good luck

Hi all,1) Any example (few lines of code) on how to write a VBA wrapper for a COM addin, in excel 97?2) When the addin creates an object in memory (say a curve object), how to get this object to update itself automatically (with some sort of counter)?Kind regards,Ab