Here are some bugs that I've found after using Pro 3.5 for a few minutes.
These all occurred in 3.3.5 so nothing new.
Thanks for the reply @RTPL_AU . If you hit this editing bug again feel free to reach out to me. I'll direct message you my contact info. The ArcGIS Pro Editing team is very interested understanding the problem.
@Scott_Harris Clearing the cache doesn't change the behaviour. It has a temporary effect i.e. it forces you to save edits and reload the map/project but when you start editing, the display messes up again.
I've also tried toggling between DX11 & 12, with various aliasing etc settings.
New one - Case lodged.
This is behaviour I have not seen in any earlier version of Pro.
It seems every now & then when you copy something, Pro 3.5 will have a bad moment, sometimes even blacking out the app window, including any panes you have open on other screens.
This could be any copy, such as copying a layer name, symbology text, attribute, or even layers between maps or copying the layer properties. The petit mal will be as soon as you right-click > copy or hit Ctrl-C.
This is happening enough that I feel something is up. Computer has been rebooted since installing Pro, and Pro has been closed/started many times as I work through jobs. It happens with one or multiple Pro instances running. Have swapped DX versions to test out some of the other issues.
OK. This new copy issue is the most unstable & irritating thing I've had in Pro for a while.
It 100% takes the place of the License Check bug (which seems 100% fixed now).
At any moment, with anything that you can CTRL-C or click Copy on in Pro, it will either have a small seizure or just lunch itself completely to where it has to be killed from Task Manager.
This started with Pro 3.5 and does not occur with any other app on this machine.
Anyone else have the same?
Here's a good one. It is the reason the update service to 3.5 to be disabled.
"In ArcGIS Pro 3.5, Calculate Field does not honor selection or layer filters when using SQL as the expression type on file geodatabase data"
https://community.esri.com/t5/arcgis-pro-questions/pro-update-update-to-3-5-service-down/m-p/1617623...
To be fair , adding SQL support in Calculate Field to file and mobile geodatabases is new in Pro 3.5. There is a big difference between an issue with new functionality versus functionality that is mature and been around for a while.
I don't agree with how Esri is handling the update service issue, especially if it is only because of this issue.
@JoshuaBixby which reinforces my Idea that Esri should pivot to separate Stable + Supported, and Feature Release version streams. Please upvote it!
You find a bug in version X, which is fixed in Version Y, but Y has another new showstopper bug so only option is to go back to W but lose new feature that made it a bit more efficient?
ArcGIS Pro 3.5 seems to use a database that is not the default, nor added to a project, as the destination database for geoprocessing tasks.
If you updated a project with new databases, folders etc, Pro will at times revert to using a removed fgdb as the destination database, even if that destination has never been used in a GP tool inn that project.
As Pro seems to always pick a random location from your past to do something in, this is no surprise. The fact that the destination is not shown in the PG task unless you click on the output FC name, is a pain.
Basic workflow as follows:
I've not tested it fully but using a no-template start will see the future project refer to the temporary fgdb Pro created in your tmp folder.
This does not seem to be the behaviour of remembering a previously used destination. It will revert to the wrong fgdb destination when you've never run a GP task in the new project before at all.
Local reseller/support trying tog et their head around it as well.
EDIT:
And to add to this – it will keep using the wrong database even after you’ve run a GP tool multiple times.
I’ve run the pairwise intersect tool multiple times this morning and every time the destination database is the wrong one i.e not any of the databases in the project nor the default one, and not one that I have used a a destination for any task in recent memory.
There is something going on with the way Pro 3.5 'remembers' things and the populates input fields for operations/tasks.
Doing many attribute joins, and field calculations etc today and it is prefilling the various inputs with 'stuff' from previous operations in various forms.
Doing a field calculation on a table that has a join, the output value entry will have a joined field pre-populated in the form tablename.fieldname from a previous join that is no longer in effect.
Creating a new join will have joining fields populated with old tablename.fieldname entries that are completely irrelevant to the combination that is being used.
I've also had joins not work where the output has very few matching results. The two source tables are derivatives of each other so the fields and attributes used to join on are 100% the same but it cannot match them up for some reason. Copy/paste into Excel, run VLookup and I get a 100% match.
Issue with Ribbon config backup/restore.
To test my config to try to solve some of the other 3.5 issues I reset the Ribbon. That also cleans out the QAT.
The reset did nothing for the issue I wanted to check so I wanted to restore the Ribbon config I'd exported before the reset.
Load the backup, QAT tools appear. Click OK to close Options and the QAT is reset back to clean default?
Did it a few times but behaviour is consistent (consistently wrong?) The only way to keep my beloved QAT is to restore the Ribbon config backup and then kill Pro through Task Manager.