User Input @ Python Add-in

2650
11
Jump to solution
08-26-2016 01:13 AM
Yusuf_CelilKonak
New Contributor III

Hello everyone,

While searching for how to get any user parameter @ add-in,  i found tkinter but before move forward with tkinter i'd like to ask if is there any other easy way to get user input. Just i want to get text from user and at layout i've text element and add-in button 'll only change element 's text property according to value comes from user. Only issue some kind of gui is needed to show user and get the text  expected. Any walkthrough or sample would be helpful.

Thanks in advance.

1 Solution

Accepted Solutions
Luke_Pinner
MVP Regular Contributor

I use pythonaddins.GPToolDialog to get user input from an addin toolbar. The code that does the work with the user input is contained in the tool that is called by GPToolDialog, rather than in the addin.  I package the toolbox and tool inside the addin, in the addin install directory (I use a pyt instead of tbx and py so it's in a single file).

Something like:

class Button(object):
      """Implementation for test_addin.button (Button)"""
      def __init__(self):
          self.enabled = True
          self.checked = False
      def onClick(self):
          tbx = os.path.join(os.path.dirname(__file__), "Toolbox.pyt"  )
          tool = "Tool"
          pythonaddins.GPToolDialog(tbx, tool)  ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

View solution in original post

11 Replies
DanPatterson_Retired
MVP Emeritus

tkinter doesn't behave well with ArcMap... there are threads on this issue but they are old, since most people have given up on trying it long ago. To satisfy you curiousity, have a try... maybe you can live the threads with a new report

0 Kudos
Yusuf_CelilKonak
New Contributor III

As you mention, threads old and there is not much clue, i'll try but it seems only way ArcObjects for this type issues. 

Thanks.

0 Kudos
Luke_Pinner
MVP Regular Contributor

I use pythonaddins.GPToolDialog to get user input from an addin toolbar. The code that does the work with the user input is contained in the tool that is called by GPToolDialog, rather than in the addin.  I package the toolbox and tool inside the addin, in the addin install directory (I use a pyt instead of tbx and py so it's in a single file).

Something like:

class Button(object):
      """Implementation for test_addin.button (Button)"""
      def __init__(self):
          self.enabled = True
          self.checked = False
      def onClick(self):
          tbx = os.path.join(os.path.dirname(__file__), "Toolbox.pyt"  )
          tool = "Tool"
          pythonaddins.GPToolDialog(tbx, tool)  ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍
Yusuf_CelilKonak
New Contributor III

Best solution is the easy solution. Calling scripts was the idea and this is very handy way to do that. 

Thanks Luke.

0 Kudos
EricAnderson
New Contributor II

If you put the toolbox under a secondary directory such as ..\Install\Toolbox\, you will need to make sure that Toolbox directory is included like so:

pytoolbx = os.path.join(os.path.dirname(__file__), "Toolbox\Toolbox.pyt")

ClintonDow1
Occasional Contributor II

In a nutshell, putting any extra UI functionality into an ArcGIS tool or add-in is an antipattern, as the tools are designed to be portable within ArcGIS. 

 

If you have a workflow which necessitates user input, this is a natural place to break the workflow up into multiple tasks. Before the step which would require the user input, write your data and use that data as the input for the next tool/add-in, plus whatever input the user would have supplied. This increases modularity of your tools and ensures that they can be accessed arbitrarily from any view.

 

This has the added benefit of future-proofing the workflow - say somewhere down the line someone invents a process which removes the need for user input, you can simply string your modularized workflow together in a 'wrapper' style add-in, rather than recoding the entire thing.

 

Hope that helps move things along!

Clinton

edit: for clarity

Luke_Pinner
MVP Regular Contributor

Clinton, I agree, however... this particular topic is about addins, not tools so by definition will always have some sort of UI.  I think using a tool dialog to gather input actually makes it more modular and portable as the script tool can be reused/ported/run as is without needing to rip it out of add-in UI code. 

ClintonDow1
Occasional Contributor II

Hi Luke, you're correct - add-ins will require the UI element while in contrast you could run a script tool stand-alone and use command-line args in place of the tool dialog. Im mostly trying to stress that if the task the add-in (or tool) accomplishes requires run-time input it's best broken up into multiple steps. If coded modularly your add-in/tool/console application should simply import a module containing the logic anyways and keep as much code out of the 'view' as possible.

0 Kudos
LukeWebb
Occasional Contributor III

I have not tried implementing this just yet, but my current plan for some advanced user input is to create a "OpenDialog"

And programatically place some files in a folder and make it open in this location. (e.g    Yes.txt, No.Txt, Other.txt) and let the user select a file from here.

Maybe this would work (and they could rename the file before selecting?)

I think Luke Pinners solution is probably better and the correct way to do it!

0 Kudos