Discontinuation of VBA Licensing Program

[DavidT via AccessMonster.com]

Any thoughts on this?

******************

Removal of VBA from Autodesk products

What’s happening?
As in AutoCAD® 2010, AutoCAD 2011 will not ship with VBA (Microsoft® Visual
Basic® for Applications) module “in the box†– and will require a separate
download. In addition, AutoCAD 2011 will be the last release to include VBA
support. That is, there will be no VBA support in AutoCAD 2012 – just over
one year from now (which means the VBA module will no longer even be
available as a separate download). This applies to all AutoCAD-based
products including AutoCAD® Architecture, AutoCAD® MEP, AutoCAD® Map 3D,
AutoCAD® Civil 3D®, AutoCAD® Mechanical, AutoCAD® Electrical and so on.

Why is it happening?

Microsoft has discontinued the VBA licensing program and made it clear that
they do not plan to provide VBA product enhancements in the future.
Microsoft discontinued the sale of new VBA distribution licenses in July 1,
2007. (Please visit http://msdn.microsoft.com/en-us/isv/bb190538.aspx to read
Microsoft’s statement). This has resulted in our decision to start
discontinuing VBA in Autodesk products now so that we can devote our
resources to more forward-looking technologies.

 

[vanderghast]

They still support COM API.


=======================
How does it work to use VBA outside of AutoCAD, such as for a user having
code in Excel? Does VBA for AutoCAD needed to be installed?

No. If a user is running macros in Microsoft Excel that access the AutoCAD
COM Automation API, then these macros will continue to work and do not
require that the AutoCAD VBA module to be installed.
=======================
ref:
http://usa.autodesk.com/adsk/servlet/item?siteID=123112&id=12729484&linkID=9240618



Vanderghast, Access MVP

 

[Banana]

Any thoughts on this?

VBA has been a great language, but I do think it has been really showing
its age, and given the migration to .NET, I actually was disappointed
that Access is the only product that continues to use VBA without any
..NET replacement that the rest of Office had and can't help but not
wonder why the program that uses VBA far more than the rest of Office
combined didn't get the treatment.

Nonetheless, I hope this ia sign that they will migrate Access's code to
something that can work with .NET.

Of course there is going to be the inevitable problem of needing to
continue supporting VBA for all legacy applications, but I don't imagine
this as insurmountable problem and as vanderghast has pointed out,
AutoCAD continues to be available for automation even though it may no
longer use VBA for its interior macros.

Last note. Remember that usually, Microsoft may announce
discontinuation, but that does not usually mean the support will cease-
usually for few more years before the support is also dropped, so
there's still time to migrate the VBA into whatever newest incantation
they've adopted for AutoDesk or other relevant products.

 

[David C. Holley]

Given what some of the off-the-shelf controls in ASP.NET already do, I can
see Access evolving into a beast that, while still Windows based, uses
ASP.NET with a very heavy user-friendly UI to completely hide the HTML and
other browser client technology. To the user, it'll be a simple drop and
drag to create a text box, but behind the scenes it'll be creating input
tags with the neccessary styles to position it and style it.

 

[David W. Fenton]

I actually was disappointed
that Access is the only product that continues to use VBA without
any .NET replacement that the rest of Office had and can't help
but not wonder why the program that uses VBA far more than the
rest of Office combined didn't get the treatment.

You're saying that the other Office programs now support .NET? In
which version of Office was that introduced?

 

[Banana]

You're saying that the other Office programs now support .NET? In
which version of Office was that introduced?

Yes. Apparently since 2003 (I thought it was 2007), but only for Word,
Excel and Outlook.

http://en.wikipedia.org/wiki/Visual_Studio_Tools_for_Office

Furthermore, in more recent version there was also better support for
interoperability - I came across an MSDN article about mixing'n'match
legacy VBA code with newer .NET code for those programs.

Why they skimped on Access, the heaviest user of VBA and most likely to
benefit from the migration, escapes me.

 

[David W. Fenton]

Why they skimped on Access, the heaviest user of VBA and most
likely to benefit from the migration, escapes me.

Probably because it was a non-trivial task. Likely the dependency on
Jet/ACE had something to do with it.