Python Add-Ins for Pro - without use of Visual Studio?

[DanielGreene]

I like being able to create a toolbox and then turning that into a toolbar via a PYTHON add-in without having to have Visual Studio on my PC.  I hope this capability will be available with ArcGIS Pro.

[curtvprice]

I asked about this at what I think was one of the first Holistic Testing sessions on Pro in the fall of 2015. There are no plans to do this, the main reason I was told at the time is that Pro is that this functionality doesn't "fit" as well -  Pro is built within the WPF environment and add-in development really needs to happen in that environment. This means it needs to be done in .NET. Maybe things have changed, but I doubt it.

In Pro it's a lot easier to dock tools into the ribbon, this may get you the functionality you need:

Save a custom set of geoprocessing tools—ArcGIS Pro | ArcGIS Desktop 

Another approach that doesn't require .NET is to use the ArcGIS Pro Task Assistant. Many user-developed VBA and ArcObjects applications I have seen over the years would lend themselves to being built in Task Assistant, guiding the user through a set of workflow steps to accomplish a task.  I suggesting taking a closer look at Task Assistant if you haven't tried it yet.

[DanielGreene]

Curtis,

Thanks for the reply.  I have developed a toolbar with 11 tools using ArcGIS 10.3.  All of them are currently written in python.  Initially one of the tools was written in C# making an all python toolbar not doable.  I rewrote that tool in python and now it is much easier to maintain.  Now that the add-in created toolbar does not involve visual studio it is faster to produce new updated toolbars and does not require two programmers (one whom owns Visual Studio).  Since python is the tool for users it only makes sense to be able to create an add-in with only the software delivered with ArcGIS and not having to deal with Visual Studio which in itself is harder to learn than a programming language.  I find this decision of ESRI's frustrating. 

I will look into your potential alternative solutions but the existing toolbar is documented in many pages of documentation which means that I will probably have to purchase visual studio should the company I'm contracting for jump to ArcGIS Pro.  Admittedly Visual Studio and .NET are very powerful but I played around trying to create a universal app and wow - complex to stumble through on your own!

I checked out one of my toolbox python scripts with pro and converting it from 2.x to 3.x will be a snap (just tabs and spaces mixed and \ instead of \\ on pathnames).  On one of the tools I have a graphics timer and I was surprised that it ran but never showed the progress bar. 

Hopefully ESRI will have a change of heart and support creating an add-in using python.  I like being able to have all of my tools in a standard toolbox and password protecting certain parts of the code (keeping those parts small for performance).  Once the toolbox has been modified I simply drop it in the area to create the add-in toolbar - so easy and quick.

Dan

[curtvprice]

You are welcome, glad you found this info helpful.

it ran but never showed the progress bar. 

This is one reason this is not an easy port... in Pro (and this is supported in the Windows WPF programming model) everything is multi-threaded, so, in a way everything runs in what we think of as "the background" in ArcMap. I find it confusing still in Pro when I run a tool and there is not a lot of feedback that anything is happening. You still should be able to show a progressor, since it is supported: SetProgressor—ArcPy Functions | ArcGIS Desktop 

[DanielGreene]

Hi Curtis,

It is not an easy port but I'm guessing that the person who set up the original python add-in could do it.  The rationale for the decision should be based on users needs and not having support for a python toolbar is a big plus for ArcGIS desktop and a negative for Pro.  I would think that once PRO is well debugged that a python ADD-IN could come along so that may be what ESRI is waiting on.  It only makes sense to me because the existing one for 10.x is so beautifully done and works so well.  If it has not been used that much it may be that there needs to be more documentation/examples on the part that requires a little python code.

In summary, I guess this is a good deal for C# and Visual Studio programmers but a negative for ArcGIS software only capabilities.  On the plus side I'm very glad that the use of a python toolbox stays intact with PRO.  The best alternative may be to drop the ADD-IN and just teach using the toolbox.  I don't know at this point and will need to experiment with the other suggestions but I would really like to avoid use of VS.  I guess it could be worth setting up a VS project to only do a toolbar and nothing else.

We have one tool on the ADD-IN that I originally wrote using Oracle Pro Fortran, then in Microsoft Basic (before .NET), then ported to C# via a contract, then ported again by another contract due to a major system change.  It was getting very messy at that point - difficult and expensive to maintain.  I completely re-wrote the program in python and that is definitely the easiest code to work with and maintain.  I will say that VS is great for forms for those with VS training but for most of our tools the Toolbox generic form with parameters works great.  And of course the ADD-IN toolbar simply fancies that up a bit making the tools a bit more friendly and easier to access but not any more functional than the toolbox.  The toolbox also allows protection of small critical pieces of the code.  I have found that password protecting very large programs in a toolbox becomes way too slow but if you pick out the parts needing protection and import them as a separate callable tool that all works well.

There are plenty of uses for Visual Studio other than creating an ADD-IN.  We have a PC/Field Data Recorder data entry program that could stand to be written as a Universal App using VS (Visual Studio) at some point unless python forms becomes more portable across different platforms. 

Dan