This is one in a series of VBA How-To articles on my blog:

How To: Assign a Macro to a Toolbar or Menu

Here Joel ( by the way the person who specified the VBA for Excel ) describes in one of the chapters why VBA is dead for good.
Microsoft just need to push new things to make money. If they did not break this, no one would be upgrading since the tools today are just fine…
Investements of customers in existing VBA code – hmmm, I don¥t think that this interests Microsoft a bit.
The change goes as far as WinAPI will be replaced by WinFX => EVERYTHING has changed.
I have finished the book over the weekend and it was very much worth reading.

I have exchanged a number of emails over the past couple of years with Stephen Bullen. He and I met up…

This all seems to be a big negative.

On one side, MS have suggested that we not use VBA any more because it has no future (what was wrong with it anyway?)

On the other, they have this replacement with the promise of a “edit and continue” in v2 – oh, and BTW… it only works when you upgrade all of your clients to the latest version of Office, half of the Excel object model is gone and you can’t embed code in your documents anymore.

I’m already developing solutions outside of Excel in VS.NET C#. It’s a great tool but I’m *really* confused as to where Excel VB is going.

I think when Excel’s Macro Recorder moves to .net, that’s when I will too.

Rob, whenever this issue was raised in respect to VSTO, the reply has always been that having code contained within a document/workbook is seen as a security risk. So I doubt if we’ll be able to embed .NET code within our workbooks. As for VBA, Microsoft’s unwillingness to touch anything to do with VBA might actually work for us in this case, as it would involve some work to split the VBA project out of the documents.

Regards

Stephen Bullen

I can just copy the single XLS around and know it’s going to work, no installation hassles.

Ideally, .net source code would be stored the same – within the XLS file.

Does anyone know (or have an educated guess) of how this will work with later versions of Excel?

Yes and no . It very much depends on your situation and what you do with which apps. If most of what you do is ‘joining the dots’ of the Office object model, there is very little difference between the VB.NET and VBA code (you just need to be more explicit in the way you refer to variables, e.g. using Excel.xlPaperSizes.xlA4 instead of just xlA4). There are lots of little gotchas (such as not being able to For…Each through the cells of a Range object), but yes, you can manipulate Office to almost the same degree and with almost the same ease as with VBA. At the moment, the ‘hooks’ that allow you to attach VB.NET code to documents only works for Excel and Word, not Access. None of the ‘On…’ (such as OnKey, OnAction etc) are available, nor are the special procedure names in Word (such as Sub FileNew). Excel automation also suffers from the major problem of stopping working if you change regional settings, and trying to share your code with others (particularly those not connected to the same network) is quite a bit harder than VBA.

The preceding is, of course, talking about Office 2003 Professional and the Visual Studio Tools for Office for the code-behind bit, and really only applies for new developments. While it is possible to extend VBA-based applications with VB.NET code by creating a hybrid solution, that scenario is officially unsupported by Microsoft.

So far, Microsoft’s focus has been on making Office available to those that have adopted .NET, rather than making .NET integrate well with Office and existing VBA-based applications. I’m hoping than Office 12 will see some enhancements that make .NET approachable by the non-programmers that make up most of the typical Office developer base – including having a single IDE that brings .NET and VBA together.