|
POST
|
Hi Robert - Thanks for weighing in on this. Its become a pretty important sticking point in our implementation. Ed
... View more
Thursday
|
0
|
0
|
64
|
|
POST
|
I should have further explained that the DockPane implementation follows the MVVM pattern -- as seems to be recommended. The logic in the Pro Window is defined in the code behind. Ed
... View more
a week ago
|
0
|
1
|
119
|
|
POST
|
All - The code above is being executed from an ArcPro DockPanel. I realized I have similar code -- that works -- which is being executed from an Pro Window. So... I took the code from the DockPanel and implemented within a new Pro Window. And it works! The data updates are made and the Undo button is enabled. If anyone has a clue on why this is the case, I would really like to understand what is going on. Thanks, Ed
... View more
a week ago
|
0
|
2
|
119
|
|
POST
|
All - I've been trying to find my problem for days and am stuck. The attached snippet has code that updates feature attributes inside an Edit Operation. When executed the updates are applied as expected, but the ArcGIS Pro "Undo" does not become enabled. The crux of the code is below. The code is attached. Any suggestions would be GREATLY appreciated. Thx, Ed --------------------------------------------------------- EditOperation editOperation = new EditOperation() { Name = "Roll Phases" }; editOperation.Callback(context => { // update stuff }, listOfFeatureClasses); try { bool creationResult = await editOperation.ExecuteAsync(); } catch (GeodatabaseException geoex) {}
... View more
a week ago
|
0
|
4
|
166
|
|
POST
|
Robert - Thanks for the detailed reply. Very helpful. Turned out that the crux of my problem was that I was using the Maplex engine without realizing it Thanks again, Ed
... View more
a week ago
|
1
|
0
|
151
|
|
POST
|
I may be missing something, but Pro labeling *always* seems to remove duplicate labels... even when I have the "Remove duplicate labels" option set to "Do not remove". Am I missing something? Any insights would be much appreciated. Thx, Ed
... View more
a week ago
|
0
|
2
|
218
|
|
POST
|
Actually. I just now had the same experience with another feeder. - Ran Update Subnetwork. - It completed successfully, but no new ElectricSubnetworkLine feature was present. - Closed Pro - Opened Pro a new the subnet line was present for the feeder. This isn't the expected workflow, is it? Thx, Ed
... View more
2 weeks ago
|
0
|
0
|
107
|
|
POST
|
Hi John - Thanks for the feedback. Weird. I closed Pro. Logged out for the day. Came back and there was the feeder in the ElectricSubnetworkLine feature class. Maybe I was hallucinating yesterday? Ed
... View more
2 weeks ago
|
0
|
1
|
107
|
|
POST
|
All - I'm finding that, once dirty areas are cleaned up, that Update Subnetwork usually returns expected results. But sometimes not. In the example below I built a subnetwork for feeder 17FL012010 - its the gray line at the bottom. Thing is, all that appeared is what seems to be a line graphic. There is no new entry in the ElectricSubnetLine feature class. I can't select the line or even perform a Pop-up on it. The breaker (red box) has a subnetworkname assigned, but nothing else does. Any suggestions on what might be going on would be much appreciated. Thx, Ed
... View more
2 weeks ago
|
0
|
3
|
162
|
|
POST
|
Robert - Thank you for the reply. To be clear, this is a "Trace" Network, not a "Utility" network. That said, I've followed your steps exactly -- to the point of making sure there are *no* dirty areas in the database after completing my edit and validating and saving. I still get the same result. If I change the normal position of a device from open to closed, then perform a trace which has a barrier condition of normal position being "open", then the trace still at the newly closed device. FWIW - I've also made sure that the domain codes are as expected; Closed = 1; Open = 0. Ed
... View more
3 weeks ago
|
0
|
0
|
171
|
|
POST
|
Hi Anne-Yvonne- This makes sense. I'll give it a try. Thanks! Ed
... View more
4 weeks ago
|
0
|
0
|
118
|
|
POST
|
FWIW - We've decided to continue our current Delete History detection process going forward with the UN. Even though we could probably find these in the branch versioned tables, the combination of having the information in one known place, plus not needing to worry about the effects of pruning make us feel best about keeping the same process. Ed
... View more
a month ago
|
0
|
0
|
111
|
|
POST
|
Hi – I’m seeing unexpected behavior after I add a new “Network Attribute” to a Trace network. Here are my steps. 1. Disable Trace Network Topology 2. Add a new Network Attribute named “NormalPosition” of data type Long 3. Use Set Network Attribute to assign this network attribute to a (Long) field named NORMALPOSITION_A 4. Enable Trace Network Topology 5. Change the value of NORMALPOSITION_A on a feature from “Closed (1)” to “Open (0)”. Save edits and validate topology. 6. Perform a trace with a barrier defined to stop at NormalPosition = “Open”. The trace stops at the newly opened device, as expected. All good. 7. Change the value of NORMALPOSITION_A on the same feature back to “Closed.” Save edits and validate topology. 8. Perform a trace with the same barrier condition and it STILL STOPS at the device which was changed to “Closed” Any suggestions on what I might be missing would be much appreciated. Thx, Ed
... View more
a month ago
|
0
|
6
|
234
|
|
POST
|
Dan - Thanks much for the reply. Right. I should have mentioned that after creating the features I saved the edits *and* validated the topology. No difference in results. I also tried the "Apply To Diagrams" tool on the "Trace Network" toolbar. Also no luck. Ed
... View more
a month ago
|
0
|
0
|
149
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | a week ago | |
| 1 | 05-14-2026 07:31 AM | |
| 1 | 05-11-2026 02:55 PM | |
| 1 | 01-07-2026 12:34 PM | |
| 1 | 01-04-2026 05:14 PM |
| Online Status |
Online
|
| Date Last Visited |
20m ago
|