VBA support extended to ArcGIS 10.1?

JeffreyHamblin · ‎08-31-2011

On this What's coming in ArcGIS 10.1 page, I found the following:

At ArcGIS 10.1 there will not be an ArcObjects VBA SDK nor will we support new VBA development with ArcGIS for Desktop. There will be an optional separate setup for legacy VBA support in the ArcGIS applications. This will require an additional license authorization similar to ArcGIS 10.

We are making VBA available if needed so existing solutions can continue to work while the code is being migrated to .NET. We recommend all users with VBA code start migrating now to an add-in or custom extension using the ArcObjects SDK for .NET or Java. This is the end of Esri's support of VBA as a development or customization language for ArcGIS.

Is this a softening of the hard cut-off that seemed indicated in the ArcGIS 10.0 to 10.1 Deprecation Plan document?

Does not supporting new VBA development, yet supporting legacy VBA mean that it will run, but not be editable in 10.1 (with the additional setup and license, of course)?

I am writing Add-Ins going forward, but it would be nice to know precisely what the status is for VBA.

AlexandraFairbarns · ‎09-01-2011

To support this, I cant comment on what the status of vba is with regards to support in arcgis, what i can say is that we have clients calling up left right and centre about vba enabled arcgis tools not working at all in arcgis 10. I knew this may happen but I too thought that these may still work in arcgis 10 with lagacy vba, but alas i am now re-creating everything for arc10 (which is a good thing for future versions - and we are adding them into add-in packages). For us, most errors tend to be with naming conventions and the process/order by which elements that make up the tool are called. I too would like more clarification on what exactly ESRI meant.

Alex

JohnHauck · ‎09-02-2011

This is largely based on the amount of feedback we received regarding the depreciation of VBA. This was by far the most common question to our SDK support unit for ArcGIS 10.0. A large majority of the comments were based around the fact that this has been, for many years, such an integral part of ArcGIS and the day to day workflows that are common for many organizations and as you all have mentioned, our clients are in an effort to move away from this but it will take time. The key message I feel is that if you have critical workflows that currently rely on VBA you should make every effort possible to move these to .NET for example. Along with the deprecation of VBA from Microsoft we don�??t want any of our customers to get stuck in a bad place if one of the critical workflows they relied on with VBA no longer works. If you call support for a VBA question with 10.1 a common question back will be to verify if it occurs in say an add-in or if it�??s VBA specific. Support for VBA specific issues will be very limited. With 10.1 Beta 1 we distributed a VBA compatibility setup. All indications I have heard at this point will be to do the same for 10.1 final. You will still have a editor but no local SDK content.

BrianJohnson · ‎09-09-2011

So...I need some help with is or someone to point me to a URL that explains how this transition will actually work in practice.

I currently use the built-in Visual Basic Editor to write VBA code that helps automate some work in ArcMap and ArcCatalog. I am familiar with this tool, since it works the same as in Excel or Access.

Once VBA is taken out of ArcGIS - will there be a new .NET editor in place of the VBE?

If not - does that mean I need to have a copy of Visual Studio 2010 - and write add-ins or actual applications to accomplish the work that I currently perform using VBA routines in the VBE?

When I hear 'start migrating your VBA code now' - I just don't understand what I should be doing.

Thanks for any resources you can point me to that will help me deal with the loss of the VBE.

Brian Johnson

RichardWatson · ‎09-09-2011

VBA is an environment which is embedded in ArcMap. When that goes away then you will need to rewrite/repurpose your code to use some other tool. The most obvious choice would be to port the code to VB.NET for which you would use Visual Studio. There are also many other choices which include Python, C++, C#, Java, etc. Regardless of which choice you make the code you generate will not be stored in the map document (mxd) because none of these are embedded solutions.

AlexanderGray · ‎09-09-2011

My understanding is 10.1 will offer limited support for VBA. What exactly does limited mean?
In ArcGIS 10, there is limited support, however once you acquire the VBA license, you still have the embedded VBA environment in ArcMap (and the other applications too.) You also have the VBA help.

My understanding is, in ArcGIS 10.1, you will still need to get the VBA license and you will still be able to execute VBA code all be it with limited support, presumably through custom commands or events.
My question is, in ArcGIS 10.1, will there still be a VBA editor in ArcMap or not? If your code runs, hooray but if not will you be hooped because you cannot edit it?
It says no VBA SDK, presumably that means no help, no samples, no templates, does it mean no vba editor?

SaptaNugraha · ‎12-02-2012

If you have ArcGIS 10.0 installer, you can try this way. VBA editor menu on ArcGIS 10.1 will appear by install the files from ArcObject SDK VBA of ArcGIS 10.0 (don't install from setup.exe):
1. \ SDK_VBA \ VBA \ VBAOF11.msi
2. \ SDK_VBA \ VBA \ 1033 \ VBAOF11I.msi

RobertDouglas2 · ‎12-04-2012

Is there any indication what the next language to be deprecated will be? How long will C++ or VB supported? Which are seen to have the most longevity, Python or C#? These might be the questions to start asking.

ClaibornPhillips · ‎03-14-2013

I've recently upgraded from 9.3.1 to 10.1 SP1. We had a lot of pretty complex VBA code infused MXDs. So I went about trying to convert them to VB.NET Add-Ins and had a lot of problems, probably because I'm not developer, just an analyst and novice developer. So with the enterprise wide upgrade deadline approaching we decided to make use of the VBA licenesing option in 10.1. You do get access to the VBA editor. Some of our old VBA MXDs work fine while others fail on some odd and seemingly minor issues. For example, loading a list box with attribute names from one of the layers in the TOC fails, but if you step through it while debugging that part works only to fail later at a call to IMxDoc.PageLayout.Page. My confusion and what I believe is one of the critical issues when they say "unsupported" is that without the SDK, the intelli-sense doesn't bring up the 10.1 ArcObjects, but the 9.3.1 ones it was built with. the VB.NET API help says IPageLayout interface is now superseded with IPageLayout3, but that's not accessible through the intelli-sense so I'm not sure if I can use it in the VBA environment or if it's just not accessible due to the lack of support. This is probably another example of something that would be a mole hill for an experienced developer, but for many of us analyst turned jack of all trades types it's a bit daunting.

My biggest disappointment with the transition process is the lack of literature out there for converting VBA into VB.NET Add-Ins. There's a few, but they're relatively limited. The link below is to one of the better guides I've found. It sketches out the basics but I'd be great find another more involved example out there:

http://www.esri.com/news/arcuser/0311/recycling-vba.html

Hope this was of some help,

Claiborn

RinkeHeida · ‎08-27-2013

A VB.Net editor is now available as an extension to ArcMap:

http://www.aris.nl/dotnetscripting_arcmap

The VB.Net code is stored in the MXD as you were used to with VBA. Edit, build and run within your ArcMap session.

You will have to use VB.Net instead of VBA, but the differences between VBA and VB.Net are not that great. Especially as you don't need Visual Studio. VB.Net is used as a scripting language within ArcMap.