Latest Contributions by MarcoBoeringa

@JeffBarrette and @HannesZiegler , I found the culprit. It is not the setting of the priority, but getting the CIMLabelClass.name property that fails on the Foreground Thread, since that is used as lookup key in the dictionary, it raises a KeyError:     ... View more

@JeffBarrette , As a last thought, I replaced the bare excepts with "except Exception:". This did not make any difference, still an exception raised on the Foreground Thread, so the exception raised by the CIM edit is not a system-exiting exception. ... View more

By the way, I installed the official first release of .NET10 next to the existing .NET8. This was under the assumption that Pro 3.6, as previously hinted by ESRI, might switch to .NET10, which is postponed to 3.7. So, unless there are parts of ArcGIS that already switched to .NET10, I assume the .NET10 installation shouldn't interfere. But if I understood it well (I am not a .NET developer), you target a single version with an app, not multiple, so this is again unlikely to play any role. ... View more

@JeffBarrette and @HannesZiegler , I have been digging a bit deeper: The example code I showed you regaring the CIM issue was a slightly modifed version of the original. The original is below: # Change the label class "label priority ranking" 'priority' value for cimLabelClass in cimLyr.labelClasses: # Double check we got a label class if type(cimLabelClass).__name__ == "CIMLabelClass": try: if missingLabelPriority == False: arcpy.AddWarning("labelPriorityByLayerDict: {}".format(labelPriorityByLayerDict)) cimLabelClass.priority = labelPriorityByLayerDict[cimLabelClass.name] arcpy.AddWarning("CIM LabelClass priority: {}".format(cimLabelClass.priority)) else: maxLabelPriority += 1 cimLabelClass.priority = maxLabelPriority arcpy.AddWarning("CIM LabelClass priority: {}".format(cimLabelClass.priority)) except: arcpy.AddWarning("*** WARNING ***: Failed to set the 'Label Priority Ranking' Maplex label engine setting of layer '{}'!".format(lyrToAdd.name)) pass Now, obviously, I am getting an exception on the Foreground Thread. But besides the CIM edit, there is also a dictionary lookup going on ('labelPriorityByLayerDict'). Now technically and programatically, that dictionary is guaranteed to contain the key being requested, so shouldn't error out, as it is in fact based on reading the exact same set of layer files being modified here. However, to get further insight, I first re-tested my previous observations, confirming what I saw before: This again shows the Foreground Thread throwing an exception during the CIM edit, but not the Geoprocessing Thread. I then decided to also test the contents of the dictionary: As you can see from the last two images, the dictionary is SUCCESSFULLY created in BOTH cases and contains the value 1 to set as label priority. This now unequivocally tells me the issue is with the actual CIM edit. I see no other way based on these results: cimLabelClass.priority = labelPriorityByLayerDict[cimLabelClass.name]   ... View more

@HannesZiegler  Based on my experiences, this ArcGIS Pro Idea may also be something to have a look at for a future version of Pro: https://community.esri.com/t5/arcgis-pro-ideas/add-ability-to-disable-arcgis-pro-3-6-new-quot/idi-p/1669229/jump-to/first-unread-message ... View more

@HannesZiegler  By the way, I don't know if it has any relevance, but please take note that I am still on Windows 10 (now with ESU extension), so it would be good to test anything on that version of Windows if possible. ... View more

@HannesZiegler , No, unfortunately I will not be providing a reproducible case for you regarding the threading issue. My tool, and the multi-threaded parts of the code, is part of a major sophisticated geoprocessing workflow coded in Python that has some 20k lines of Python code over a few dozen modules. To demonstrate other issues, I have in the past made available earlier versions of the tool to the Dutch branch of ESRI, but each time this turns out into a nightmare in terms of the amount of work for me to get anything logged. I won't be doing that again based on these past experiences. Sorry. I do think you should look at the CIM issues and the Python exception I saw happening when run on the Foreground Thread. This issue is unrelated to the 'concurrent.futures.ThreadPoolExecutor' and threading issues I saw, and should be relatively easy to test in trying to reproduce it. I already supplied part of the needed code as you know. ... View more

Hi @HannesZiegler , I have unfortunately identified a few more issues that I want to report here. I honestly do not have the time and energy now to go through the whole process of getting them logged as bugs. I already wasted a whole week trying to wade through issues getting my main geoprocessing workflow to fully work again in Pro 3.6, at least on the Background Thread for now (which now works). This is to much. The issues: - With Foreground Thread processing, if I use a Python 'concurrent.futures.ThreadPoolExecutor' with a function similar to the one below as input to the executor, where there is a gc.collect() in the 'finally' except construct, it will hang / stall Pro. Removing the gc.collect() from the 'finally' construct, lets the script continue. This does not happen with Background Thread processing, the gc.collect() call does not cause issues in that mode in combination with usage of 'concurrent.futures.ThreadPoolExecutor'. I do not know if this is actually a Pro bug, or a bug in Python 3.13. There are several references to (fixed) issues related to gc.collect in the Python 3.13 release notes, see the linked full release notes for the references to gc.collect() in relation to these issues: Add sys.unraisablehook() to customize how "unraisable exceptions" are logged python/cpython#81010 C implementation of functools.lru_cache python/cpython#58581 At least one of them seems to have quite a bit of history, and may have seen changes in e.g. 3.11 as well, but I didn't check. def some_function(): try: blabla except: blabla finally: some_clean_up gc.collect() - With Foreground Thread set, CIM edits seem to cause Python exceptions. Please note I haven't checked this extensively, I just noticed it in one particular case that is present in my workflow. I have not tested whether this applies to all CIM edits on a Foreground Thread, or just the specific one I happen to use in my workflow, which is the setting of the label classes' Maplex label priority ranking. E.g. see the script example below, where the exception will be raised on a Foreground Thread but not when running the same code as Background Thread. cimLyr = lyr.getDefinition("V3") i = 1 # Change the label class "label priority ranking" 'priority' value for cimLabelClass in cimLyr.labelClasses: # Double check we got a label class if type(cimLabelClass).__name__ == "CIMLabelClass": try: cimLabelClass.priority = i except: arcpy.AddWarning("*** WARNING ***: Failed to set the 'Label Priority Ranking' Maplex label engine setting of layer '{}'!".format(lyrToAdd.name)) pass i += 1   ... View more

@HannesZiegler , I have now reported these issues to the Dutch branch of ESRI, so hopefuly they get reproduced and logged as bugs. Unsurprisingly, for the Get Count tool issue, a bug was already logged. ... View more

@HannesZiegler and @Kimberly-Saballett  Just to clarify a bit more: regarding the detected issue with Python "concurrent.futures.ThreadPoolExecutor" hanging when run in the ArcGIS Pro 3.6 Foreground Thread, when I say "hangs" I literally mean hangs, the application does not crash nor does it throw open the ArcGIS Pro error reporter, but it simply becomes unresponsive at the end of the ThreadPoolExecutor execution, and doesn't continue processing. I need to kill Pro from the Windows Task Manager to stop the application. ... View more

Hi @HannesZiegler , I unfortunately have identified two other issues in Pro 3.6: 1) - The Get Count  geoprocessing tool now fails with a non(!) enterprise geodatabase enabled ordinary PostgreSQL enterprise database feature class. This used to work in Pro 3.5 and below. According to the "What's new in Pro 3.6", the Get Count tool had changes applied for Pro 3.6, that seems to break this option. See the images entirely below. 2) - Using a Python "concurrent.futures.ThreadPoolExecutor" seems to make the geoprocessing in Pro 3.6 hang at the end of the thread pool processing if the processing is run in the Pro Foreground Thread. I do not see these hangs if Pro 3.6 is set to run in the background Geoprocessing Thread, which is the default. ... View more

@HannesZiegler  I ran into a highly confusing issue with one of my main custom build Python scripts after the ArcGIS Pro 3.6 / Python 3.13 upgrade. When I attempted to run the script, which runs perfectly fine in Pro 3.5 / Python 3.11, the script immediately errored out with an "indentation error". However, there are none. Visual Studio Code, and PyScripter show the code as fine with their internal syntax checks. One thing I finally noticed, was that the error seemed related to a commented out code section: for renderRule in renderRulesInit: renderRules.append(renderRule.split('|')[0].rstrip(' ')) ## for layeredRenderRule in layeredRenderRulesInit: ## layeredRenderRules.append(layeredRenderRule.split('|')[0].rstrip(' ')) This code section lived directly under an: if __name__ == '__main__': styleFolder = arcpy.GetParameterAsText(0) styleName = arcpy.GetParameterAsText(1)  code section. Having such commented out section there, was never a problem with Pro <3.6 and Python <3.13. As a test, I changed the code with comment to this, so with comment lined out with the rest of the code: for renderRule in renderRulesInit: renderRules.append(renderRule.split('|')[0].rstrip(' ')) #for layeredRenderRule in layeredRenderRulesInit: # layeredRenderRules.append(layeredRenderRule.split('|')[0].rstrip(' ')) and then the script ran! Note that having similar comments lined out to the entire left of a code line in other functions is *no* problem, it is just those sections directly under '__main__' that now in Python 3.13 seem to cause these false "indentation errors", blocking execution of the script in Pro. Not sure if this is a bug in Pro 3.6, or more likely in Python 3.13. Can you confirm this? At least it would be good to document this behavioral change in the Pro Help if this is a deliberate and intended change in e.g. Python 3.13. Marco ... View more

I have never used it, and are also not much of an AGOL user, so can't comment on whether it would work there, but it sounds to me you may wish to use ArcGIS Dictionary Symbology:   https://pro.arcgis.com/en/pro-app/latest/help/mapping/layer-properties/dictionary-renderer.htm https://github.com/Esri/dictionary-renderer-toolkit   Although a lot of the documentation and the initial usage was geared to military mapping and symbology, you can actually use it for custom symbology as well in more recent versions of Pro. Here's a blog post documenting how to create a "custom" dictionary: https://www.esri.com/arcgis-blog/products/arcgis-pro/mapping/create-custom-dictionary-styles-for-arcgis ... View more

@JesseCloutier . The editing isssue is resolved for me. Thanks! ... View more