Integrate C++ program into VBA


Quant Headhunter
I teach how to build VBA/Excel DLLs in the UK, I have lecture PPTs with some example code.
If you want them drop me a line at my pimping address.

(no, you're not allowed to question why a pimp teaches c++)


Director, Wasserman Trading Floor/Subotnick Center
Not sure if this is helpful, but for Baruch students with access to Books24x7
(see the Newman Library home page) there is a new book posted today:

Financial Applications using Excel Add-in Development in C/C++, 2nd Edition by Steve Dalton John Wiley & Sons © 2007 (584 pages)
Including example projects that demonstrate the potential of Excel when powerful add-ins can be easily developed, this book is a complete how-to guide for the creation of high performance add-ins for Excel in C and C++ for users in the finance industry.

I did not read this book yet - just thought it might be relevant.


Prof .H.
Using ActiveX you can also access to Bloomberg servers and pull anything you want into excel or access. This is used rather for historic, static data. For live data you just type functions in excel cells.
This requires the machine to have Bloomberg API installed with a valid license, I believe.
Matlab has the financial datafeed toolbox which can get BB, Reuters data directly.
This means we can't just get the data from home computers.
How about creating our own database with C++ and VBA codes so we can exchange them?
I'm really interested in this. I believe many members here have years of experience in VBA, .NET, C++, etc so if they are open to share, I'm all ears.


Quant Headhunter
Bloomberg licences come in several flavours, and you may find that the academic licence you have access to has limitations like the number of series that can be downloaded.

As for Steve Dalton's book, I think you can assume that it works with Excel 2007, because we were on the technical beta team for E12, and his stuff was used to check that it works.

.NET is not a great way of driving Excel. MS has been trying to move people to this mess for years, and their net progress has been negative. At one point they were going to so brain damage Excel by removing add-ins and VBA macros that it resembled the sort of pretty but low function shit that Macintosh users prefer instead of a tool for grown ups.

XLLs are not the easiest interface, and VBA DLLs require you to think clearly, but debugging .NET stuff can be a nightmare.
The following is what I read from some article online:
"With the arrival of, API calls are now being phased out. You should only use API calls in VB 6 or earlier"

I've heard that .net is really powerful and useful, but I've never touched it. And I doubt if I even have a basic idea about it. Any suggestions or recommendations on learning .net or, specifically, the

I don't have experience with VBA or, but worked in MS environment for a few years, I know they do a good job in education so they can lure admin/dev to their technology. MS is a huge marketing machine.

After some searching, here is a webcast that may be useful:

It also have a link to more general Office webcasts, but they seem to be less related with VBA.
Microsoft Office System Webcasts: Enhance Your Skill Set with Expert Tips: Enhance Your Skill Set with Expert Tips

If you poke around the site a little more, you may figure out how to search or narrow down to the area that you are interested in. I am sure they have more webcasts or online learning stuff for VBA/Office.

They also have live seminars where you can register and go for free. You can get popcorn, drinks, and maybe a book if you can answer a few silly questions.

Be aware, though, what they tell you in these seminar/webcasts probably works 90% of the time so you will like their technology and get hooked. But then the other 10% you would have to google all over the place, or try to decipher some MS KB articles, and debug to figure it out.
I had researched into using .NET to create components for Excel earlier this year (Jan 2006). Here is what I found:

1) Debugging problems is quite tedious. Is the problem in your Excel code, .NET code, or an environmental issue? When .NET code bombs out, the error does not surface.

2) The .NET component is quite slow.

3) I think an additional add-on has to be purchased for Visual Studio.


Sorry, but I really disagree with your views.
1) Debugging a problem is a skill. You could send messages from your .Net code to excel and it could display the error, or you could write the error messages to a Log file or the system EventLog.

2) What .Net component are you referring to? I am using a .Net assembly which connects to a C++ program [legacy code] and updating cells in Excel in Real-time. It isn't slow. I guess it would be naive for me to judge this issue. I would need to figure out what you were trying to achieve and how it was designed.

3) Nope, no additional purchase.

Here are some examples.
If you wanna integrate C++ into VBA, why not using COM? Currently I am taking intern at trading floor. I found most of trader or trader assistants working with Excel for every minute. Therefore that is the reason why VBA is more popular. C++ is only a tool for Quant or Quant developer. Why we need c++? Since the pricing models of most industry-level trading system are developed by C++. Why we choose COM not Dll or Xll? COM is language independent. That means you can develop COM by C++, C#, VB.NET. But no matter which one you choose, they all implement an universal interface. Therefore from client's view, they are same. This is very flexible and convenient. Since I do touch this topic for short while, if you are interested, we can do research together. Thanks



Older and Wiser
the last time I used COM it was a nightmare. I don't know how it is now since I haven't touched COM since aroun 2000. At that time, it was a half baked idea and a pain in the butt to code using C++ and the ATL.

Also, I thought COM was obsolete because after that there was COM+ and God knows what else. Ah, whatever you mentioned about Language independence, that was only in fantasy land. If it has changed recently, please enlighten me.
Ah Alain, you are mistaken. The original execution, as I saw it, was brilliant. Here's how it worked circa 1998:

1. Contractor with C++ experience but no COM expertise hired to work on code maintenance.
2. Contractor, wishing to accumulate valuable buzzwords for his resume, immediately suggests use of COM at first opportunity. Technical manager A blows off request, tells contractor to work on job at hand.
3. Manager A replaced my manager B in a sloppy office reshuffling. Code with COM checked into source control the second A is gone.
4. Contractor puts COM on resume.
5. Contractor leaves in the middle of his contract for new job requiring COM, paying $10/hr more.

Contractor wins, Microsoft wins, everybody wins!