http://blogs.msdn.com/excel/archive/2008/01/16/clarification-on-vba-support.aspx

Sounds pretty good to me

But that’s the problem. If ANY & EVERY automated system needs to meet IT/IS department standards, then EVERYONE creating or maintaining such systems SHOULD be using something like VSTO *AND* have their code, forms, and code-to-spreadsheet interfaces reviewed by IT/IS before deployment. That WILL prevent users who lack either the time or the inclination to learn and/or apply professional development practices from developing systems going forward.

OTOH, if you want to continue to allow confirmed amateurs to do some decidedly nonprofessional development, then you have to accept that it won’t be easy to hand it off to others to maintain.

So, will VSTO be able programmatically and dynamically to change all aspects of Excel’s UI as well as run all OM methods and read and set all OM properties?

In terms of VBA replacements (and I quote):
‘Deployment deployment deployment’

Any VBA replacement must have at least as good a deployment story. Whether good = secure or good = easy I think is a big debate point at the mo.

Where do people think the best value (for users) would be:
A simplified VBA type thing with macro recording or
A developer focused thing (packaged with Office), no recorder, but better OO, better .net integration etc?

I like a few others here have fallen into VBA as the first language I have played with and like others I am fairly well self taught and I know that despite playing with VBA I still have a hell of a lot to learn. So the talk about these other options is interesting to me from a question of portability. As like others I have no idea about the other programs.

The reason I like VBA is that it’s embedded in Excel and it provides me the ability to perform complex analysis in the background with user friendly forms up front to provide a communication device to explain complex natural resource economic issues to the unconverted. As just about every computer has Excel on it (occasionally yes I have a problems between Mac and PC which highlights my lack of knowledge), so the ability to put your file on a memory stick and run it in front of a new audience on their machine gives you a huge advantage over someone with a file that needs to either be loaded onto the machine with an installation program or that they have to use their own laptop to display the file.

Until I find a programming language where its just simple a case of plug and play your file I’m fairly sure that like most people there is no incentive to make the transition. I’m sure that whatever the future coding language is within the Excel framework that we will adapt.

By adding other languages and such it opens XL up to the professional developer. When developers recognize that XL can be a robust platfrom on which to build very powerful and cost effective apps we will all be better off. The more XL can be used in conjunction with managed code the better off we will be.

But if the objective is to move away from the simplicity of recorded VBA then I think we are heading down the wrong path. It removes the small business users and amateurs from the picture which in my opinion would be a real shame. There are lots of tools for the professional developer. Adding one more to their arsenal will not hurt so long as it is not at the expense of the casual user.

One other note. I see a lot of discussion here or IT departments v. Accounting, for example. Not much mention of the small business, maybe one to five people that doesn’t have any departments. I don’t know how many of them use VBA – but I’m sure less of them will use something more complicated!

Given that we can apply some CAS-models á la VSTO the built-in access feature in VSTA may not be a security issue.

Kind regards,
Dennis