nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to link GUI developed by using PYQT with ArcMap 10

SreenivasaRaoPigili

Hi All,

   We have developed a GUI with the help of PYQT.
   Now we have to add this GUI with ArcMap as a extension. Meanwhile some of the tools in the GUI (i.e Combobox - to display list of layers) needs to interact with .Mxd also

   Can you guys please help on this.

THanks and Regards,
Sreeni.

Find more posts tagged with

Accepted answers

All comments

RichardFairhurst

Hi All,

   We have developed a GUI with the help of PYQT.
   Now we have to add this GUI with ArcMap as a extension. Meanwhile some of the tools in the GUI (i.e Combobox - to display list of layers) needs to interact with .Mxd also

   Can you guys please help on this.

THanks and Regards,
Sreeni.

Although I would love to be proved wrong, I believe that ESRI has not found a way to get GUI interfaces developed in Python to interact compatibly with ArcMap. They both compete for OS attention and identical resources and generate errors or crashes. So I have not heard of a way to make a python GUI part of an ArcMap extension.

JamesCrandall

Although I would love to be proved wrong, I believe that ESRI has not found a way to get GUI interfaces developed in Python to interact compatibly with ArcMap. They both compete for OS attention and identical resources and generate errors or crashes. So I have not heard of a way to make a python GUI part of an ArcMap extension.

As an alternative, we are integrating Toolbox/Scripts that have the various parameters predefined and launch these toolboxes per the appropriate Python Add-In event and button, tool or menu. That is, the Toolbox acts as the GUI and is opened at opportune moments (during specific events of the various tools we employ in the Python Add-Ins).

For example, here is a ToolClass that implements the onRectangle def that we 'do some stuff', then launch a Toolbox .tbx".

class ToolClass2(object):
    """Implementation for my_addin.tool (Tool)"""
    def __init__(self):
        self.enabled = True
        self.shape = "Rectangle"   

    def onRectangle(self, rectangle_geometry):
        mxd = arcpy.mapping.MapDocument("CURRENT")
        df = arcpy.mapping.ListDataFrames(mxd)[0]
        ext = rectangle_geometry
        thepoly = arcpy.Polygon(arcpy.Array([ext.lowerLeft, ext.lowerRight, ext.upperRight,  ext.upperLeft]),df.spatialReference)

        # '...do stuff
 
        #open the .tbx
        pythonaddins.GPToolDialog('\\\\theUNCpath\ToolShare\geoproc\MyToolbox.tbx', 'TheScriptToRun')

"TheScriptToRun" has been predefined with the desired input parameter types. The code in this Toolbox script peforms the required processing using the parameters input by the user (Dates, Date Ranges, Folders, FGDB's and all kinds of other things such as combo box drop downs and radio button lists).

RichardFairhurst

I have similarly used the tools schema configurations to customize standard tool input dialogs (for example populate a combobox based on a selection in another combobox). It, however, suffers performance degradation if you have too many interacting items on a dialog (I had about 15) especially if they perform database queries in response to user inputs (which mine did). The degredation affected opening the tool and making dialog selections. I ended up using VB.Net to rebuild the interface as an Add-In and was much happier with the performance and GUI flexibility.

JamesCrandall

I have similarly used the tools schema configurations to customize standard tool input dialogs (for example populate a combobox based on a selection in another combobox). It, however, suffers performance degradation if you have too many interacting items on a dialog (I had about 15) especially if they perform database queries in response to user inputs (which mine did). The degredation affected opening the tool and making dialog selections. I ended up using VB.Net to rebuild the interface as an Add-In and was much happier with the performance and GUI flexibility.

Completely agree with this. And not just an issue with performance, there are lots of limitations to the Python Add-In. Since my .NET dev environment has been limited, I've had to get creative with the Python Add-In and Geoprocessor object development. It is a pain to get it all integrated and implemented, but comes with the advantage in distribution compared to a COM/ArcObject component that requires installer packages and such.

RichardFairhurst

Completely agree with this. And not just an issue with performance, there are lots of limitations to the Python Add-In. Since my .NET dev environment has been limited, I've had to get creative with the Python Add-In and Geoprocessor object development. It is a pain to get it all integrated and implemented, but comes with the advantage in distribution compared to a COM/ArcObject component that requires installer packages and such.

.Net Add-Ins are as easy to distribute as Python Add-Ins. I see no advantage to Python if an application needs a GUI.

RichardFairhurst

I see no advantage to Python if an application needs a GUI.

I should clarify that statement. Python has several advantages, with the greatest being a low learning curve and a powerful syntax that greatly reduces the amount of code that has to be written to perform an operation. Also it does not require an application as costly as the full version of Visual Studio to use it (although the free Visual Studio Express version is somewhat usable). That being said, when a GUI is integral to an application, Python is severely limited. .Net will perform much better, but that does assume that the learning curve can be overcome.

LindsayRaabe_FPCWA_3-1642566150522.png

ZurAinZulkafely_1-1642575689850.png

JamesCrandall

I should clarify that statement. Python has several advantages, with the greatest being a low learning curve and a powerful syntax that greatly reduces the amount of code that has to be written to perform an operation. Also it does not require an application as costly as the full version of Visual Studio to use it (although the free Visual Studio Express version is somewhat usable). That being said, when a GUI is integral to an application, Python is severely limited. .Net will perform much better, but that does assume that the learning curve can be overcome.

One thing not discussed in all of this is the value of the developer changes too. Coming from the ArcObjects/COM environments and application dev (along with lots n-Tier architecture with .NET, ADO.NET app and business tier dev and RDBMS integration and Procedural code development) Python is extremely limited in comparison. With that, my value as a developer decreases too --- well, if the only environment available is now Python, then my value only resides there. But as those other skills are not being employed, they tend to get lost eventually or new technologies and methods come up.

Of course, this is also highly dependent upon the overall tech-direction of an organization. Should cost become prohibitive to development options, the ArcObjects/.NET/RDBMS stack is simply not available.

I will say that you can get creative (you have to) in order to get things done with Python. Things like connecting to and using attribute databases (non spatial RDBMS like Oracle or SQL Server) is possible and we do that now with libraries like cx_Oracle. The advantage is in overcoming administrative barriers such as change control (I don't need to wait 2 weeks for adding a PL/SQL package and just write the SQL into the Python tool).

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.