Select to view content in your preferred language

ArcGIS Pro 3.5: Bugs found

1796
24
4 weeks ago
RTPL_AU
Frequent Contributor

Here are some bugs that I've found after using Pro 3.5 for a few minutes. 

  1. When using Copy > Paster Special to copy a feature class in a FGDB the new FC retains the alias of the old FC.

  2. During an edit session, Pro will stop showing the edited geometry once an edit is completed (press F2, etc) and revert to showing the old geometry on screen until you save and refresh the map.
    You can still interact with the geometry in its new location (edit vertices will show the correct geometry while using the tool but revert to display the last saved version when you finish the tool operation.)

    This bug is extremely confidence inspiring to clients when you are sharing a screen during a VC to go over an earthworks design revision.

  3. When copying text or numbers from a popup window you may get a leading space or tab character when you paste the selection into something else e.g. Excel, Notepad, etc.

  4. There are still some PDF issues. When exporting a layout, an aerial image in ECW that is clipped to a boundary only partially displays in the PDF. 

These all occurred in 3.3.5 so nothing new.

 

 

 

Tags (2)
24 Replies
Scott_Harris
Esri Regular Contributor

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.

0 Kudos
RTPL_AU
Frequent Contributor

@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.

0 Kudos
RTPL_AU
Frequent Contributor

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.

0 Kudos
RTPL_AU
Frequent Contributor

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?

0 Kudos
RTPL_AU
Frequent Contributor

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...

 

0 Kudos
JoshuaBixby
MVP Esteemed Contributor

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.  

0 Kudos
RTPL_AU
Frequent Contributor

@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? 

0 Kudos
RTPL_AU
Frequent Contributor

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 open Pro with a template project, with an empty fgdb as default (to prevent random temporary bits & pieces all over the place)
  • Once open, I add and specify folders & fgdbs to use as default, and remove all other folders/fgdbs.
  • I do some work and save the project.
  • When re-opened - and you go to execute a new GP task, the orginal template fgdb is shown as destination, not any of the fgdbs added to the project and specifically not the default fgdb. 

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.

0 Kudos
RTPL_AU
Frequent Contributor

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. 

 

0 Kudos
RTPL_AU
Frequent Contributor

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.

0 Kudos