Comments on: 7 Reasons for ESRI not to Drop VBA http://geographika.co.uk/7-reasons-for-esri-not-to-drop-vba?utm_source=rss&utm_medium=rss&utm_campaign=7-reasons-for-esri-not-to-drop-vba Developing geo-technologies Tue, 31 Jan 2012 15:43:37 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Duncan Hornby http://geographika.co.uk/7-reasons-for-esri-not-to-drop-vba/comment-page-1#comment-54 Duncan Hornby Thu, 05 Nov 2009 22:13:23 +0000 http://geographika.co.uk/?p=106#comment-54 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... 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…

]]> By: Bog http://geographika.co.uk/7-reasons-for-esri-not-to-drop-vba/comment-page-1#comment-53 Bog Thu, 05 Nov 2009 15:51:27 +0000 http://geographika.co.uk/?p=106#comment-53 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! 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!

]]> By: Tom Magdaleno http://geographika.co.uk/7-reasons-for-esri-not-to-drop-vba/comment-page-1#comment-50 Tom Magdaleno Tue, 03 Nov 2009 21:22:06 +0000 http://geographika.co.uk/?p=106#comment-50 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. 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.

]]> By: Dave Miller http://geographika.co.uk/7-reasons-for-esri-not-to-drop-vba/comment-page-1#comment-32 Dave Miller Thu, 15 Oct 2009 11:26:01 +0000 http://geographika.co.uk/?p=106#comment-32 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 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

]]> By: SeaJunk http://geographika.co.uk/7-reasons-for-esri-not-to-drop-vba/comment-page-1#comment-31 SeaJunk Wed, 14 Oct 2009 23:58:22 +0000 http://geographika.co.uk/?p=106#comment-31 Re: The field calculator VBScript will still be around so maybe we'll see a vbscript and python parser in the field calculator. Re: The field calculator
VBScript will still be around so maybe we’ll see a vbscript and python parser in the field calculator.

]]> By: admin http://geographika.co.uk/7-reasons-for-esri-not-to-drop-vba/comment-page-1#comment-25 admin Fri, 09 Oct 2009 20:25:56 +0000 http://geographika.co.uk/?p=106#comment-25 <a href='#comment-20' rel="nofollow">@Nico</a> 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. @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.

]]> By: Nico http://geographika.co.uk/7-reasons-for-esri-not-to-drop-vba/comment-page-1#comment-20 Nico Tue, 29 Sep 2009 23:34:05 +0000 http://geographika.co.uk/?p=106#comment-20 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. 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.

]]> By: Michalis Avraam http://geographika.co.uk/7-reasons-for-esri-not-to-drop-vba/comment-page-1#comment-19 Michalis Avraam Tue, 29 Sep 2009 02:35:26 +0000 http://geographika.co.uk/?p=106#comment-19 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?). 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?).

]]> By: Kevin Dunlop http://geographika.co.uk/7-reasons-for-esri-not-to-drop-vba/comment-page-1#comment-18 Kevin Dunlop Mon, 28 Sep 2009 23:47:52 +0000 http://geographika.co.uk/?p=106#comment-18 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. 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.

]]> By: James Fee GIS Blog » Blog Archive » In defense of VBA http://geographika.co.uk/7-reasons-for-esri-not-to-drop-vba/comment-page-1#comment-17 James Fee GIS Blog » Blog Archive » In defense of VBA Mon, 28 Sep 2009 17:28:24 +0000 http://geographika.co.uk/?p=106#comment-17 [...] 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 [...] [...] 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 [...]

]]>