Latest Contributions by JohnJones

We are a bit hesitant to add yet another per layer boolean state specific to tracing (and another matching tab to the Contents pane to author it), but have mentioned something like this in the past.  One solution would be to say that tracing can only trace 'snapable' (& visible) layers so toggling off this state would control both snapping and tracing on that layer.  Internally we haven't made a consensus that this would be a positive or intuitive change.  The argument for hinges on saying tracing is a form of snapping (to ensure the new geometry coincides with the existing geometry) and the argument against basically says that is hogwash and the two features are independent (for example snapping works reasonably the same in 3D while tracing only works in 2D). A middle ground would be to expose a tracing option "Trace only snappable layers" or some such then we need to agree on the default state. ... View more

Travis, This isn't quite how editing in ArcGIS Pro works.  Essentially each time you make an edit the system determines which databases are being referenced by that edit and it on-demand starts editing on those datasets.  In the case of databases that support undo that edit session is left ongoing so that undo/redo/save & discard operations function as expected, but as a side effect schema editing operations such as add field are disabled until the edits are saved or discarded (much like ArcMap).  To simplify the model of working against multiple databases simultaneously (& avoiding choosing a single database to edit, the way ArcMap does) as you make edits the set of databases being edited can gradually grow but save and discard is applied consistently to all at once.  In cases of databases that do not support undo/redo the edits are saved automatically after the edit is made.  In some cases (enterprise geodatabases) where some tables are undoable (versioned tables) and some are not (non-versioned tables) this can get quite complicated to explain.  Another complicated example is branch versioned feature services where named versions can be edited with undo/redo but default cannot.  You do not need to disable editing on layers in order to perform schema edits (any such case would be a bug, probably an instance of some code leaking a lock or otherwise getting out of sync across threads).  Currently if you undo your first edit save & discard are disabled but redo is enabled, which can be very confusing.  This case will be addressed when 2.4 ships and discard will remain enabled (with save disabled) when you are still editing but do not have any outstanding edits.  Clicking discard will disable redo, as the session is complete and release any locks needed to perform schema updates. In short, the best way to consider ArcGIS Pro editing is that while things initially appear editable you are not Really editing the database until a command or tool attempts to perform a write, at which point the normal logic that ArcMap would execute in "Start Editing" (which may fail and is treated similarly to the edit itself failing) is executed automatically by Pro. The checkboxes exposed in the Contents pane are purely to control which layers are allowed to edit through the tools,  They do not directly effect edit locks as you might expect.  For example, two layers referencing the same feature class may have different edibility check box states.  Clearly editing one effects the other and certain functionality such as Geodatabase Topology validation may effect many feature classes in that database, so just because a layer is unchecked in the contents does not provide a strong guarantee against the underlying feature class from being modified. (Geoprocessing tools for example pay no heed of these settings).  If you require a stronger guarantee it is best to manage it at the database permissions level not at the application level. Thanks, John Jones ... View more

As soon as a user saves or discards their edits the lock is released and another client can edit (no need to close the project).  For performance reasons, we cache edibility of layers / datasources so the incoming app may need to open the editing status window or the editing view to the contents pane to refresh this cached state so other controls can observe the lock that was preventing them from editing has been released (as both file gdb & shapefiles are single user solutions this isn't as expected as for enterprise geodatabases).  Particularly if they had previously tried to edit while the first user was still editing and thus got a message that the layer isn't editable (failure to upgrade the lock). ... View more

Thanks, this is certainly on our radar and have been able to reproduce crashes on one machine but not yet under the debugger (or even on my development machine without the debugger going).  As yet something unknown is causing this to be more/less likely to occur.  Will have an update when we learn something. ... View more

Not directly, but note that EditOperation.Modify(Inspector) does pretty much the same things as Inspector.Apply() does. ... View more

In Pro editing tools now have selection built into them to reduce reliance on the selection tool (much like selection was built into the ArcMap Edit tool but not really for other tools that also required selections).  The UI for both selecting and using editing tools are centralized in the Modify (& Create) dock panes to reduce reliance on the ribbon. Currently we are rather restricted on hotkey usage since there seem to be many conflicts with different view types (editing tools mainly need to operate in all views so if one view type uses a hotkey for navigation it is off limits).  We are working through a story to better allocate the scarce resource of keyboard hotkeys (post 2.3 work ongoing).   ... View more

I would suggest that you read the active map once at the beginning of your command / tool execution and when done add the result to that map (don't ask for active map again)  Essentially avoid asking questions twice when they can either take time to retrieve or return different results the second time (unless you really want that behavior). ... View more

Brian, note that in ArcObjects only the base table is editable, not joined layers (represented as RelQueryTables), so the table that you are referencing isn't the joined table.  However in Pro the inspector object has been loaded with the layer's values (not going directly to the geodatabase base table) so all fields are there and hence they are fully qualified.  As a convinience (and consistent with the ArcMap attributes window's behavior) the Inspector will allow you to modify the fields in the left hand table through the joined view (like ArcMap the joined fields are read only through this view).  To get behavior more similar to ArcObjects you would need to load the inspector with a Core.Data Table or FeatureClass rather than the higher level joined Layer.   At that point you should see non-qualified field names for that table and no joined fields from other tables.   Thanks ... View more

Off the top of my head I can't recall any specific differences between Pro and ArcMap in how Align edge works that would explain this.   If you are using GDB topology you could try switching over to map topology instead and see if that setting fails similarly.  In map topology the topology graph is always in the map's SR, with GDB topology it would be in the data's native SR (and projected on the fly for feedback / visualization).  If you can reproduce, of course I would be interested to test locally (including on 2.3). ... View more

In the contents pane on the 'editing' view you can control per layer edibility of layers in your map, the map topology only contains editable layers so unchecking layers will restrict the participation in your map topology.   You can also setup configurations using Tasks to bulk turn on and off layer properties at once if you have several different configurations (this also works for visibility, selectability and snapability). ... View more

I don't think its too small to post as an idea. I believe we will need to solicit user feedback and add an optional setting as to whether or not changing the unit should keep the same distance (in the new unit) or keep the same number (interpreted differently in the same unit) rather than changing the current behavior.  I see reasonable use cases for both.  The question becomes more of a matter of priority, for which Ideas is helpful in determining how important this is for our users. ... View more

While not ideal, there is at least one work around... ArcGIS.Desktop.Editing.Templates.EditingTemplate contains Task<ImageSource> GeneratePreviewAsync(int width, int height) which will generate a swatch.  So the process would be three fold. a) Generate a layer rendered with the symbol you want. (maybe you already have one though) b) Generate a template that falls into that renderer class (again might already have one). c) Get the preview off that template. Of course a utility that generated a swatch from a symbol directly would be preferred.(edit. see Charlie's reply on SymbolStyleItem) ... View more

Align has been ported to Pro as well as the ability to trace while Splitting polygons. ... View more

Note that 'V' is taken in Pro and we will need to find a new hotkey for activating this behavior, of course it will be customize-able, as all hot keys are.  Also the option of using the XOR pen as we did in ArcMap to guarantee visibility is not possible in Pro so instead we will probably need to expose a marker symbol configuration so users can pick what marker symbol they use to symbolize the vertices with (whether that is a full symbol in the symbol model or a restricted symbol that can be drawn entirely on the video card is an open question).  Currently we don't have a setting to override sketch vertex symbology (green & red boxes) but that is also desired.  Trying to get a better idea about user expectations would it be sufficient to show vertices only of visible/snappable layers or do we need to include all visible layers (including non-snapable) layers?  Also we need to decide how far to show vertices.  ArcMap would show all vertices for features that are close to the cursor (several pixels) but not all vertices of all features on the map.  I'd like to only show those vertices close to the mouse (maybe 3x or 5x snapping tolerance, if we used just the snapping tolerance we could use the snapping cache to fulfill requests and it would be much faster but probably that isn't far enough ).  I find it confusing that ArcMap will show some vertices clear across the map from the cursor because they are part of a feature that is also close to the mouse but won't show other vertices relatively close to the mouse (much closer than the ones that are being shown). Personally I just haven't see much benefit in the V key as the snap tips indicating that I'm over a vertex are good enough, its rather obvious where corners are so its mainly about discovering vertices that are close to 180 degrees and it isn't clear why finding a vertex is important (I tend to think of edge snapping as just as good).. In cases where it can matter (Utility Network and Network datasets) we follow the rules of those datasets to insert vertices at edge intersections where appropriate. I have always found the ability of the renderer to place markers at vertices in a more permanent fashion more useful and controllable (I wouldn't turn it on and off often, I would just author the layer for how I expect to see the data while editing (in a dedicated map that is symbolized for the purpose of digitizing).   ... View more