VBA and VB6 with ArcGIS: What's the Story?

Coming out of the ESRI Developer Summit last week, and hearing some buzz about this on Twitter, we figured it would be a good time to catch everyone up with the ArcGIS support story for Visual Basic 6 (VB6) and Visual Basic for Applications (VBA).  We wrote a few notes on this a while back, but here's the scoop.

Visual Basic 6 Support

This development environment is fully tested, documented, and supported for use with ArcGIS through version 9.3.1.  

The v9.3.1 release will include a version of the VB6 Software Developer Kit (SDK) for both ArcGIS Desktop and ArcGIS Engine.  For the past few years Microsoft has been phasing out support for VB6, finally considering it unsupported as of 2008.  Due to this, ESRI will not be releasing a VB6 SDK, nor supporting VB6 at the ArcGIS 9.4 release.  We continue to encourage users and developers to migrate their projects and code to more recent versions of Microsoft Visual Studio which use the .NET Framework.

What about your existing VB6 code?  Well on the one hand, your code may just continue to work with version 9.4, but one should not count on that for planning purposes.  In addition, VB6 documentation, samples, and other resources for earlier versions of ArcGIS will still be searchable online.  As for the user community, VB6 users will probably be there for some time into the future, but you should probably expect that the size of this group will continue getting smaller.  On the other hand (and more importantly) you will not have an SDK for VB6 at version 9.4 nor will technical support services from ESRI or our distributors be available, so our ability to support what you are doing will be significantly limited.

Another point worth mentioning is that ArcGIS will no longer install the Microsoft VB6 runtime at v9.4.  This is something to consider if you plan to deploy VB6 solutions to machines on which v9.4 is installed.

Check out this migration post to see how to use the Visual Studio Update Wizard to convert your code.

So to summarize:

For ArcGIS through v9.3.1:  VB6 is fully supported.
For ArcGIS 9.4:  VB6 will be unsupported.  Your code may just work, but there will be no VB6 SDK, nor technical support services. 

VBA Support

For about 12 years now since version 8.0, ArcGIS Desktop users have been able to take advantage of the embedded VBA Editor to write macros, code modules, etc.  The status of VBA going forward is this.  VBA is fully supported through ArcGIS Desktop version 9.3.1, however developers are encouraged to use supported versions of Microsoft Visual Studio when extending the ArcGIS Desktop applications.  When ArcGIS 9.4 is released, VBA will no longer be recommended for use, however it will still be available in order to support legacy code and applications.

So to summarize:

For ArcGIS Desktop through v9.3.1:  VBA is included and fully supported.
For ArcGIS Desktop 9.4:  VBA will be available if needed, fully supported but not recommended.

Published Monday, March 30, 2009 10:51 AM by jbarry
Filed under: , , , ,

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

theavey said:

After DevSummit it sounds like ESRI is going to replace the VBA scripting environment with Python. The only problem with this is the inability to cut VBA code into VB6 solutions when you want to move a prototype to a more robust environment.

Will there be a scripting / prototpying environment that will be as seamless as the VBA/VB6 environments?

March 31, 2009 2:31 PM
 

scott bridwell said:

What will happen with the vb script components embedded in various pieces of ArcGIS such as the field calculator and label rendering? Will these features exist for the foreseeable future or will a new scripting framework replace it?
April 6, 2009 11:25 AM
 

Simon said:

I assume this has come around more because MS are discontinuing VBA & VB6? http://msdn.microsoft.com/en-us/isv/bb190538.aspx Its good that ESRI appear to be enhancing python support at 9.4 - However, I imagine a number of users are not keen on using Visual Studio, and prefer to customise the mxd's themselves as opposed to creating .DLL files.
April 6, 2009 7:02 PM
 

alaframboise said:

Sorry for the delay folks.  

Scott: As with all releases, we are working hard to maintain all aspects of backwards compatibility with the 9.4 release.  Features such as VB scripting will still be supported but we will be considering alternative methods to scripting as we move forward.

Simon: As technology evolves, we evolve as well.  When a development environment is no longer supported by a vendor, it makes it very difficult for us to build and design future versions of our software on those technologies.  

And to your second point, there are definitely advantages and disadvantages to writing code in the application tier vs in DLLs.  One thing to keep in mind however is that writing pure .NET DLLs is considerably easier than writing and deploying traditional COM DLLs.  DLLs also make it easier to separate tiers of business logic so that code can be reused across many different applications.  That said, we also recognize the benefits of writing code within the application framework itself, and are taking this into serious consideration for the future releases.

AL

EDN Team

April 9, 2009 4:04 PM
 

Randy said:

As someone who basically dabbles, but has benefitted enormously from AML, Avenue, VBA, Python , and ModelBuilder over the years, without ever really becoming a "developer," sentences like this: And to your second point, there are definitely advantages and disadvantages to writing code in the application tier vs in DLLs. One thing to keep in mind however is that writing pure .NET DLLs is considerably easier than writing and deploying traditional COM DLLs. DLLs also make it easier to separate tiers of business logic so that code can be reused across many different applications. Give me the heeby jeebies. I have no idea what that means. I just would like to know what programming language I need to learn now to keep providing useful customizations. Currently, Python seems to work with the geoprocessing tools, but ArcObjects is what I would use for non-geoprocessing tasks (i.e., rename everything in the table of contents...or, zoom to selected features, add a bookmark, update the layout, send to printer....) Will (does?) Python have the ability to go into that sort of area? Thank you
April 10, 2009 6:28 AM
 

Hornbydd said:

I've been developing ArcObjects solutions for clients and projects since ArcGIS 8.1.

Usually this is in VB6/VBA and more recently I'm starting to get to grips with VB .Net. I personally  find python too slow and does not offer the rich toolkit of objects that ArcObjects has.

You might as well put a gun to my head and pull the trigger if you remove the ability to write code within a MXD!  I do most of my coding within the VBA editor because its fast prototyping environment.  For example, if one of my colleagues needs a solution that the geo-processing tools are unable to achieve then I usually knock out some quick code in an MXD.  Some of my biggest and most successful projects have all run within a single MXD!

As a developer I understand its considered more clever doing it in visual studio but as a consultant who has to deal with clients and colleagues with differing skill levels, resources, time and money the MXD is often the only way to deliver.

Consider this...

I had to work for a client to process a significant amount of data as well as providing a tool for them to use at the end of the project.  Despite them calling the shots, their own IT department would not allow DLLs... So how can I do the "clever" thing and develop an extension, the answer was an mxd!

Please don't take away the ability to write custom code, forms and toolbars from a MXD.

April 13, 2009 3:57 PM
 

FS said:

Change is always hard to handle.  When Avenue was replaced with VB, I about had a heart attack.  But now I see how much better it is.  This will probably turn out the same.  The initial shock is hard, but then you realize how much better things are after.

May 5, 2009 9:05 AM
 

stevel said:

When you're looking at upgrading VB Script, could you please focus on building in some error checking? "User Interrupt" doesn't help when trying to debug a complex VB Script labelling expression.

Thanks.

May 5, 2009 8:48 PM
 

nur said:

Where I can get arcgis scripting for beginner?
May 7, 2009 8:14 PM
 

alaframboise said:

You may want to start with this.

http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=About_getting_started_with_writing_geoprocessing_scripts

or here:

http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=An_overview_of_writing_geoprocessing_scripts

Allan

EDN

May 14, 2009 2:14 PM
 

pierre.k said:

What about VSTA? Does ESRI plan to support this platform in the future?

June 24, 2009 10:21 AM

Leave a Comment

(required) 
(optional)
(required) 
Submit