Is wxPython incompatible with ArcMap add-ins and tools?

[JohnMorgan1]

I have written an Add-In that generates a dialog box that allows the user to select Census Bureau TIGER/Line data layers by description (year, state, state-wide or county layer, layer type) instead of using the standardized file naming convention (which has changed often over the years.)  I previously wrote a version of this tool as an ArcMap Add-In in VB.NET using Visual Studio, but unfortunately, each version of ArcGIS is tied to a particular version of Visual Studio.  I was able to successfully compile the VB.NET Add-In in Visual Studio 2008 (supported by ArcGIS 10.0).  The finished Add-In continues to work in ArcGIS 10.4, but the same source code no longer compiles in Visual Studio 2013 (supported by ArcGIS 10.4), so it is impossible to make any modifications to the Add-In. 

I decided to try rewriting it in Python, since ESRI is pushing Python as the new development language for customizing ArcGIS.

I have written a script in Python that uses the wxPython package to build the dialog box and GUI controls, and it works fine when I run it from the Python command line window inside ArcMap.  Unfortunately, when I try to incorporate it into a Toolbox tool, it crashes ArcMap when I try to run it, and when I try to make it into an ArcMap Add-in button, it runs exactly once.  The second time I try to run it as an Add-In button, it crashes ArcMap.

Is wxPython incompatible with the Toolbox tool and the ArcMap Add-In implementations?  I assume that both of these involve putting some kind of wrapper around the Python script

[DanPatterson_Retired]

The last time wxPython questions were asked were about 4-7 years ago.  Arc* prefers their own gui construction and generally doesn't behave well or at all with other.  I am sure you can design equivalents using either a conventional or python toolbox as documented in the help.

https://community.esri.com/ideas/6945-form-builder-for-python-tools as for ideas, which you have already seen.

Moving forward with PRO, QT is distributed with Anaconda, so there is some built-in gui potential that may behave better with Arc* products... but only time will tell

[JohnMorgan1]

The agency I work for has a concurrent license for ArcGIS 10.4 not ArcGIS PRO, and I don't have enough clout to push for upgrading to ArcGIS PRO.  Is QT more compatible with ArcGIS 10.4 than wxPython?  In particular, is QT more compatible with ArcGIS 10.4 Add-Ins and/or Toolbox Tools?  I wouldn't like to spend the time converting my current app from wxPython to QT only to find that it has the same problem as the wxPython app.

[DanPatterson_Retired]

John ... Forget QT if you are on 10.4.  I don't even recommend developing your own guis unless you plan to work completely outside of the Arc* environment for the bulk of your work.  Pro is nice, developing conventional toolboxes in it are easy and clear and python 3.6 is used.  You may as well wait until you can move forward at once rather than in pieces

[curtvprice]

Is there any reason this can't be implemented using validation code in a Python toolbox (or tbx validation code)?  Validation code can be set up to be quite interactive, and using that approach would avoid having to try to get wxpython and Esri's .NET frameworks to play nice together. This approach would also work across ArcMap and Pro with no additional work.

The agency I work for has a concurrent license for ArcGIS 10.4 not ArcGIS PRO, and I don't have enough clout to push for upgrading to ArcGIS PRO.

This isn't a licensing issue, it's an IT and organization issue. If you have an ArcMap license, you are entitled to a Pro license. I also want to mention that Pro isn't an "upgrade" it's just a new, awesome tool. ArcMap is not going away anytime soon.

[JohnMorgan1]

The Add-In for loading Census Bureau TIGER/Line layers that I am currently using was written in VB.NET under ArcGIS 10.0 using Visual Studio 2008.  It has a single dialog box with a Combo Box to select the year, a Combo box to select the state within the year, a multiselect scrolling ListBox to select the geography (statewide or county layer), a multiselect scrolling ListBox to select the layer type, a multiselect scrolling ListBox containing the selected layers, a button to add selected layers for the selected year, state, geography(ies), and layer type(s), a button to remove individual layer(s) from the selected layers list, and an Exit button. 

I do not know of any components in ArcPy or the Python Add-In software that allows the design of a dialog box with 11 interacting GUI controls on it. 

The Python script that I have written using wxPython works just fine from the Python command line inside ArcMap, and I can run it any number of times.  I have to run it inside ArcMap because it is adding layers to an .mxd document, so running it from a Windows Command Line or external Python Command Line will not work. 

If I try to make a Python ArcMap Add-In that calls the script, it runs once correctly, but the second time I run it in an ArcMap session, it crashes ArcMap.  If I try to make a Toolbox Tool that calls the script, it crashes ArcMap immediately.  Since my above posts, I have tried running a sample program using PyQT that doesn't even interact with ArcMap in any way, but if I run it from the Python command line inside ArcMap, it runs once without error but crashes ArcMap the second time I run it.  For this reason, I don't think that I will bother trying to rewrite the Add-In using PyQT, since it appears to be even more incompatible with ArcMap 10.4 than wxPython is.  That's too bad, because I like the QT Designer software which makes it much easier to design a form than writing wxPython code.

Currently, the Arkansas Department of Health (where I work) does not have a GIS Coordinator, and I didn't hold that position even when there was one.  I really have no control over which ESRI products are currently licensed and available for installation under the agency multi-seat concurrent license, so getting ArcGIS Pro is not an option.

[curtvprice]

I may be being dense about this, but I still think you could do this using value tables.  The interface would have to be re-implemented somewhat as the GP tool dialog widgets are not the same. However, all the information you are gathering could be managed as lists of pathname strings, and be updated from other parameters as you change them from within validation code.

Have you opened a tech support incident on this -- it sounds like a pretty nifty tool as-is and if there is a way to get it to work, you should try.