I am trying to create a value table parameter in my python toolbox where the user selects a feature class (first column) and then the second column displays a list of the fields available to choose from based on that feature class. It sounds like that was going to be available in 10.2 but the documentation doesn't mention it.
this can be done with a regular toolbox using the "derived from" parameter where the featureclass is a parameter and field names are derived from it...I am surprised that the newer toolboxes dont have them. is there a reason for you to use them rather than the simpler incarnation?
Hi Christina Heimburg,
As we discussed in our phone conversation, this functionality is not yet possible with value tables. The code snippet that we used was the following as a workaround:
import arcpy class Toolbox(object): def __init__(self): """Define the toolbox (the name of the toolbox is the name of the .pyt file).""" self.label = "Toolbox" self.alias = "Toolbox" # List of tool classes associated with this toolbox self.tools = [Tool] class Tool(object): def __init__(self): """Define the tool (tool name is the name of the class).""" self.label = "Tool with Value Table" self.description = "Contains a model that you would like" self.canRunInBackground = False def getParameterInfo(self): """Define parameter definitions""" in_features = arcpy.Parameter( displayName= "Input Feature Class", name="in_features", datatype="GPFeatureLayer", parameterType="Optional", direction="Input") Fields = arcpy.Parameter( displayName= "Field", name="Fields", datatype="GPString", parameterType="Optional", direction="Input") value_table = arcpy.Parameter( displayName = "Selected records", name = "value_table", datatype = "GPValueTable", parameterType = "Optional", direction="Input") value_table.columns =([["GPString", "Feature Class"], ["GPString","Field"]]) params = [in_features, Fields, value_table] return params def isLicensed(self): """Set whether tool is licensed to execute.""" return True def updateParameters(self, parameters): """Modify the values and properties of parameters before internal validation is performed. This method is called whenever a parameter has been changed.""" if not parameters[0].hasBeenValidated and parameters[0].value: #listOfFields = [] #fields = arcpy.Describe(parameters[0].value).fields #for field in fields: # listOfFields.append(field.aliasName) parameters[1].filter.list = [f.name for f in arcpy.Describe(parameters[0].value).fields] if not parameters[1].hasBeenValidated and parameters[1].value: vtab = arcpy.ValueTable(len(parameters[2].columns)) if (parameters[2].valueAsText not in ('', ' ', None)): vtab.loadFromString(parameters[2].valueAsText) vtab.addRow('{0} {1}'.format(str(parameters[0].value), parameters[1].value)) parameters[2].value = vtab.exportToString() parameters[1].value = "" parameters[0].value = "" parameters[1].filter.list = [] return def updateMessages(self, parameters): """Modify the messages created by internal validation for each tool parameter. This method is called after internal validation.""" return def execute(self, parameters, messages): """The source code of the tool.""" return
Alexander... wow... that is a really ugly substitute for the conventional toolbox approach...this is remniscent of the old Dialog Designer for ArcView 3.x I wonder why they have taken this approach. It will be fun going old-school again
Dan I'm not sure that this is possible in the original toolbox becaue a value table data type is not available in the script toolbox. I have switched to a .pyt because it is much easier to deal with validation in one complete script, and all of the functionality of the script toolbox is still available within a python toolbox. Please see the highlighted portion of my image below for what I am trying to achieve. Let me know if you still think thats possible in a .tbx.
Ahhh I presume that you are referring to this type of value table
The closest are the links to working with multivalue inputs
and the in memory version of the ValueTable defined in arcpy,
So I suppose it depends upon balancing the differences between the
The learning curve for non-programmers is certainly faster with the former.
So you may be stuck unless you want to partition your existing structure into 2 parts... a data preparation tool where you replicate your additional sampling layers for a finite number of input layers, then selecting the desired field from the next combo which would show the fields for that layer much like
Additional layer 1
..........................
Field for layer 1
.........................etc etc
Addition layer N
.........................
Field for layer N
where the Field for layer ? are derived parameters for the appropriate field.
so if you don't want to partition your Sampling zones selection process as a separate tool as a prior step to your analysis, then you are pretty well stuck since adding more rows to the table may not be possible for a large number of additional layers.
It would also be useful for the documentation to indicate which arcpy functions/methods/properties are only supported by *.pyt toolboxes. It would certainly help minimizing the overkill I have seen where *.pyt's are used when a *.tbx would be more than adequate
Good luck
We have logged the following enhancement request for this issue:
ENH-000083940 - Allow parameter dependencies between columns in a value table parameter in a python toolbox.
I have switched to a .pyt because it is much easier to deal with validation in one complete script, and all of the functionality of the script toolbox is still available within a python toolbox
I'm kind of with Dan. Outside of being able to use new functionality like value tables and the isLicensed property, the pyt approach still has left me unimpressed -- it seems like an awful lot of work for not a lot of gain.
Hi Dan Patterson & Curtis Price,
In regards to using a python toolbox over a script tool please review the following docuentation which may provide some additional insight specifcally, this line:
"In a Python toolbox, parameter definitions, validation code, and the source code are handled in the same place, making it easier to create and maintain Python tools. Additionally, Python toolboxes support capabilities that script tools do not, such as value tables, composite data types, and custom license checking."
Comparing custom and Python toolboxes
ArcGIS Help (10.2, 10.2.1, and 10.2.2)
I hope this helps!
Alexander
I have read that all before. You may not have noticed the comments in my previous threads...but one is particularly useful
...this is remniscent of the old Dialog Designer for ArcView 3.x I wonder why they have taken this approach. It will be fun going old-school again...
I have no aversion to the new incarnation, it just doesn't offer anything that I currently need. I have adapted to developing toolboxes that event listeners, update scripts etc... are buried beneath the surface.
I teach...I teach to non-programmers. I do miss the excitement when one of my sociology majors finally got a simple dialog to work. I do not miss having to explain the concept of self to a philosophy major ( )
The "old" toolboxes were simple and the new ones add an extra layer of complexity which will change over time. I await the day when any GUI developer can be used that will be compatible with ArcGIS.