Latest Contributions by MarcoBoeringa

@JeffBarrette  Please note I do appreciate your efforts to try to reproduce it. I just think it needs a bit more digging and effort from the ESRI side. As I already explained to @HannesZiegler , this particular piece of code is part of larger toolbox with some 20k lines of Python code, with a few dozen Python modules. I honestly cannot transfer the whole thing. And that is what I mean with "there is a *lot* more going on". However, I am almost 100% sure we can safely ignore that fact in relation to this is issue. Why?: What it basically does is implement a sophisticated generalization workflow that generates a 150+ feature classes in PostgreSQL database. At the end of that processing, so when all the true geoprocessing work is done, the script from which I extracted the snippets, is called. It loads layer files from a custom style I developed (just an ordinary folder with *.lyrx files managed by the code, nothing special), and uses the symbology of those style layers in combination with the  symbolizedLayer = arcpy.ApplySymbologyFromLayer_management(featureLayer,symbologyLayerFile,inputSymbologyFields,update_symbology="MAINTAIN")[0] tool to update the symbology of Query Layers that were created during the previous generalization geoprocessing workflow and that point to the feature classes in the PostgreSQL database. It also transfers any label classes from the style layer to the Query Layers. Granted, the transfer of all of theses attributes / settings of one layer to another I think has become easier in Pro 3.6 with new options if I remember it well from the release notes, but my current code is based on what was possible in the past. That said, as you may now understand, by far the majority of "there is a *lot* more going on", is really unrelated to anything to do with actual feature layer objects in the TOC. It is database work and processing. Only a fraction of the code touches upon the parts that might be relevant to this issue. By the way, if by now you are wondering what the output of this whole workflow is, it is the below: topographic maps based on OpenStreetMap data... ArcGIS Renderer for OpenStreetMap - The Netherlands - Valkenburg 1:25k - UTM31N ArcGIS Renderer for OpenStreetMap - The Netherlands - Schiermonnikoog 1:50k - UTM31N ... View more

@JeffBarrette , One other thing that may be highly relevant to the issue and that I didn't mention yet, is that my tool does NOT use layers from the ArcGIS TOC, but first loads them from ArcGIS *.lyrx files stored on disk, modifies the Maplex settings per e.g. the code I showed you (in reality there is a *lot* more going on), and then finally adds them to the TOC. Maybe this is part of the issue why you can't reproduce. ... View more

Part of the CIM layer object properties:     ... View more

@JeffBarrette , I now ran the workflow with ArcGIS Pro attached to the Visual Studio Code debugger using the ESRI debugger extension. I don't think it turns up much new information, but as you can see, it is not just the label class name that got reset to 'Class 1', but all label class properties seem to have been reset to defaults in the CIM object.     ... View more

@JeffBarrette  I can talk with the labeling team to see if the smoking gun you suggest could have been caused by changes made during 3.6 development. Yes, I think you should. ... View more

@JeffBarrette Another thing I intend to do is to try to run ArcGIS Pro attached to the ESRI Visual Studio Code debugger. Maybe that will give some new insights. There is not much more I can and will do. Honestly, I do not want to sound to cynical here and I understand your frustration regarding the reproducibility, but I as an ESRI client, am not the one getting paid for debugging Pro, and believe me, there is a bug lurking here. After 25 years in IT and working with ESRI software, I can smell them from a mile's distance. And remember, my code runs perfectly fine on the Geoprocessing Thread... ... View more

@JeffBarrette , Although you say you tried to reproduce my workflow based on my script sample, your script is missing the setting of the disabling of ligatures in case Maplex spread characters is set on a label class, that I included in my last code snippets. (Background for this: these settings in Maplex are incompatible from a cartographic point of view, and cause garbled incorrectly rendered labels with two ligature characters in Latin grouped together, while the rest spread, e.g. "a...bc...d...e...f" instead of cartographically correct "a...b...c...d...e...f", unfortunately, ArcGIS Pro by default activates ligatures since it introduced support for them in Maplex).   # Change the 'ligatures' label class text symbol setting to false if gType in ['Line','Polygon']: for cimLabelClass in cimLyr.labelClasses: # Double check we got a label class if type(cimLabelClass).__name__ == "CIMLabelClass": try: if cimLabelClass.maplexLabelPlacementProperties.spreadCharacters == True: cimLabelClass.textSymbol.symbol.ligatures = False except Exception: arcpy.AddWarning("*** WARNING ***: Failed to set the label class text symbol's 'ligatures' setting to 'false' for layer '{}'!".format(lyrToAdd.name)) pass   ... View more

The layer that failed in the screenshot examples I showed, was of type Polygon by the way. ... View more

@JeffBarrette  Some more complete code sections from my workflow. The second one shows everything happening from the moment the CIM layer object is requested with 'getDefinition' until the modified version is written with 'setDefinition'. Nothing else is happening here. But to be honest, I think you have one big smoking gun right in front of you with my observation of the labelclass name being set to some "auto-generated" "Class 1" name. Some developer at ESRI baked that behavior into ArcGIS Pro, it shouldn't be to hard to find out where it is happening in the Pro code base, and that code section will likely tell you a lot about what may go wrong in the Foreground Thread.  To be honest, I even have a, now rather vague, recollection of having seen a very similar issue with these label class names pop-up in an earlier version of Pro, maybe at the time Python CIM editing was first introduced (Pro 2.4??? or so???). This issue with label class names really rings a bell to me in terms of previous ArcGIS Pro issues / bugs I had to deal with. if removeAmbiguousLabels == "Do not remove": removeAmbiguousLabelsSetting = 'None' elif removeAmbiguousLabels == "Remove within same label class": removeAmbiguousLabelsSetting = 'WithinLabelClass' if removeAmbiguousLabels == "Remove all": removeAmbiguousLabelsSetting = 'All' cimLyr = lyrToAdd.getDefinition("V3") # Change the 'removeAmbiguousLabels' Maplex setting # NOTE(!): This setting only became available from ArcGIS Pro 3.1 onwards, # and is currently only applicable to feature classes of type 'Point'. if gType == 'Point': for cimLabelClass in cimLyr.labelClasses: # Double check we got a label class if type(cimLabelClass).__name__ == "CIMLabelClass": try: cimLabelClass.maplexLabelPlacementProperties.removeAmbiguousLabels = removeAmbiguousLabelsSetting except Exception: arcpy.AddWarning("*** WARNING ***: Failed to set the 'Remove ambiguous labels' Maplex label engine setting of layer '{}'!".format(lyrToAdd.name)) pass # Change the 'ligatures' label class text symbol setting to false if gType in ['Line','Polygon']: for cimLabelClass in cimLyr.labelClasses: # Double check we got a label class if type(cimLabelClass).__name__ == "CIMLabelClass": try: if cimLabelClass.maplexLabelPlacementProperties.spreadCharacters == True: cimLabelClass.textSymbol.symbol.ligatures = False except Exception: arcpy.AddWarning("*** WARNING ***: Failed to set the label class text symbol's 'ligatures' setting to 'false' for layer '{}'!".format(lyrToAdd.name)) pass # 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: cimLabelClass.priority = labelPriorityByLayerDict[cimLabelClass.name] else: maxLabelPriority += 1 cimLabelClass.priority = maxLabelPriority except Exception: arcpy.AddWarning("*** WARNING ***: Failed to set the 'Label Priority Ranking' Maplex label engine setting of layer '{}'!".format(lyrToAdd.name)) pass lyrToAdd.setDefinition(cimLyr)       ... View more

@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