7 Reasons for ESRI not to Drop VBA
I recently learned from James Fee’s blog that ArcGIS 9.4 will be the last version that supports VBA. I can see why this is being dropped – Microsoft no longer promotes or updates VBA. Microsoft now promote “Visual Studio Tools for Office” as its replacement for VBA in MS Office products, however VBA is still in Office 2007, and looks to be kept in for at least the next version. Is ESRI acting too prematurely? I can think of 7 good reasons why VBA should be kept.
1. VBA is great for prototyping. There is no need to open up Visual Studio, create a custom tool, implement all its interfaces and constructors etc. before you can even get round to writing the code for the OnClick event of a button.
2. The code is saved in the MXD. Prototypes can be easily zipped up and sent to a client for testing without the need to run set up packages, use the add/remove programs tool, and change config files. This allows projects to be developed using an agile approach.
3. It is the easiest entry point for GIS professionals into programming. People with no programming background can use an application they are already familiar with, cut and paste a few samples from the help file and they are away.It is also an entry point into the weird, wonderful, and worringly huge world of ArcObjects.
4. It is all well and good to use Python for geoprocessing, but many tasks require ArcMap’s user interface, and the ability to visualise the data – and maybe even interact with it..!
5. There is a wealth of samples, tools, and scripts available on the web that will now be useless, or require conversion. No more copying, pasting, and running to get a task done quickly. VBA for many people is part of the daily use of ArcMap – basic subs can be bashed out in a few minutes to complete a one-off task and then forgotten about.
6. VBA skills can be transferred to other applications such as Excel, Word, and Access. For many GIS users these are the only other programs they use for daily tasks, so being able to automate them, or modify a recorded VBA macro can greatly increase productivity.
7. It is another nail in the coffin of the VB.Net versus C# argument – if no-one has used VBA then there is no reason to recommend coding in VB.Net due to familiar syntax..however that is just a personal view in an ongoing struggle to avoid having to write all future projects in C# to fit with “company standards.”
In my opinion the ideal solution would be to continue to allow code to be written and saved in the MXD, but replace VBA/VB6 with VB.Net. Why not even go further and allow macros to be recorded in ArcMap?
Still at least we’ll all now be safe from those VBA viruses going around in MXD files..
Update
One item I missed in the original post is that VBA is used for field calculations in ArcMap. I’m sure most GIS users have a few complex operations saved somewhere, all of which look to become redundant. It will be interesting to see whether Python will take its place.
[...] to be a large percentage of ESRI developers that still rely on VBA to customize ArcGIS Desktop. geoGraphika has even written a blog post outlining 7 reasons why ESRI shouldn’t drop [...]
James Fee GIS Blog » Blog Archive » In defense of VBA
28 Sep 09 at 7:28 pm
How about an 8th:
8. VBA apps can be run without requiring an install. Many organization limit what users can install on their computers yet rarely limit VBA. While a .NET may not be allowed, a VBA is.
Kevin Dunlop
29 Sep 09 at 1:47 am
Indeed, but VBA is no longer being licensed by Microsoft to 3rd parties (as of 2007), and all development has since stopped as well. There are many security holes and issues with it, and I think ESRi is doing well to phase it out. The 2+ years people have of warning about this should be plenty for people to migrate to something else (Python with the new functionality of 9.4?).
Michalis Avraam
29 Sep 09 at 4:35 am
Do not take me wrong but:
1. You do not need to explicitly implement all the interface , there are tools to do this.
2. A setup doesn’t need to be “heavy” , in fact it is as lean as VBA.
3. I agree, if you don’t need anything different to what a sample provides it’s ok to with it. As you stated it’s easy for someone with no programming experience.
4. I agree
5. I agree
6. I agree partially , if you were always to held the same position this can help, I’m not sure about people out there, but since I have moved a lot I do not rely on this knowledge to help/keep me a job.
7. I don’t really get the point, I’m no native English speaker,but I don’t think anyone’s recommending C# over Vb.Net,
this is just about deprecating VBA.
8. I don’t know if that’s possible
9. Yes that would be great, not sure if possible
Just to let you now I started doing “Magik” (Smallworld)and afterward VB6 ,I moved to PL/SQL and SQL, then Java, then C#,
then shell scripting (Solaris,Linux,AIX).This has always occurred within GIS environments, there are some more GIS offerings besides ESRI ( though I currently work in an ESRI based project)
Do not rely in one language to do your day to day work, this can easily change. Just get the roots and you’ll be prepared for every language.
Nico
30 Sep 09 at 1:34 am
@Nico
Hi Nico,
Even with the tools to set up the interface, you still need to learn Visual Studio, how to add in the ESRI tools to this, and then be confronted with a whole load of pregenerated code which would look like nonsense to any non-developer.
A set up could be very simple, but again it takes time and effort on the developer’s part to create custom installer classes and set up packages.
I agree that a developer should not fear the death of VBA from ArcGIS, but for advanced GIS users who are probably more numerous in various civil service jobs, it removes the chance of automating daily tasks themselves.
admin
9 Oct 09 at 10:25 pm
Re: The field calculator
VBScript will still be around so maybe we’ll see a vbscript and python parser in the field calculator.
SeaJunk
15 Oct 09 at 1:58 am
The dropping of support for VBA gives rise to a big question for what I would call the “non-programmer GIS community”. That is those of us who have learned GIS and picked up a bit of VBA along the way (for customisation, labelling expressions, field calculator expressions etc.) without being fully-blown programmers.
That question is what should we use now?. Clearly VBA is on the way out, and ESRI have given us a good head’s up that support for it will be dropped if we hadn’t already figured that out from Microsoft’s decision not to continue development. Can Python do everything that VBA could do? If not, should we channel our efforts in other directions?
Dave
Dave Miller
15 Oct 09 at 1:26 pm
Dave, I completely agree. Can’t we just go back to Avenue?
Seriously though, I am not a programmer and frankly I do not want to be one. I get the feeling that the future of GIS will mean you have to know programming languages. All these languages have a nasty habit of becoming obsolete every few years.
The attitude of most programmers is
“Learn how to program and then programing for GIS will be easy.”
thats like saying “Learn calculus for a job that only requires adding fractions.” I hope ESRI continues to be helpful in letting users share code to keep it simple.
Tom Magdaleno
3 Nov 09 at 10:22 pm
I am bummed. Mostly because I am foggy on ESRI’s direction after this. Looks like they are pretty tight with Microsoft now (Silverlight, etc), so whatever way MS goes, ESRI will follow no doubt. Python is pretty prevalent in ArcGIS, but as someone mentioned – not exactly hooked into the interface and all that ArcObjects have to offer. If they develop an API for Python that bridges the gap, then all is not lost. I have several MXD-based VBA apps that will have to be updated (many planned for .Net anyway), but the quick result macro functionality of VBA will be missed. Yes, Avenue was a good analogy in seeing code work or not work immediately without having to go into a compiling environment like Studio. Perhaps 9.4 will be the last version many use for a long time (even if on maintenance) like those still using Win 2K out there (as discovered in James Fee blog), Some on 8.X, and probably even those still using AV 3.2!
Bog
5 Nov 09 at 4:51 pm
Hi all,
I’m somewhat perturbed by the future of VBA. I’ve written some very large and successful projects entirely within the MXD and will be very concerned about the demise of VBA, mainly because some clients I have developed for have such a ridiculous IT policy that despite them asking for a tool their IT department won’t allow the installation of DLLs which is what .Net creates. I cannot create an extension, a command buton, or a GP function tool because they are all DLLs that you have to install and don’t get me on my soap box about administrative rights…
None of this is an issue with VBA. So I agree with the blog that if they want VB .Net, fine but for God sake don’t drop the ability to store code and customisation within an MXD.
I really hope someone from ESRI is reading this…
Duncan Hornby
5 Nov 09 at 11:13 pm