Latest Contributions by KrisCulin

Better support should be added to the SDK that specifies what versions of ArcGIS Pro are supported by a specific configuration. For example, a property in the ConfigurationManager could return a list of versions that are supported.  Only the versions at or above the versions specified would be supported and a message displayed if you are running an older version. For example, if the SupportedVersions return only "3.2.2" and the user is running 3.2.1, then a message would be displayed that ArcGIS Pro 3.2.2 or higher is required. This may be necessary if a newer SDK contains functionality that the configuration uses that older versions do not provide.  This includes something that was patched in an update like 3.2.2, not just a minor release of 3.2. ... View more

When the /config command line parameter is used on a shortcut to ArcGIS Pro and the configuration fails to load, ArcGIS Pro should display a message reflecting that failure. For example, if /config:TestPro is provided and it fails to load, then a message should be displayed: The configuration 'TestPro' failed to load. If the proConfigX file was not found, that could be included in the message as well. ... View more

Hi All, I am hoping someone in the community can help me.  Even better, someone on the AGP development team will see this post and jump on it. We currently have an AGP configuration to host our application inside ArcGIS Pro.  We started initially with ArcGIS Pro 2.6.  We just recently upgraded our code base to target net6 and we now support ArcGIS Pro 3.1+. We also have 27 docking windows in our application.  These controls are Windows Forms controls, and we host them inside of a WindowsFormsHost in the DockPane in ArcGIS Pro.  We did this in ArcGIS Pro 2.6+ and brought it forward to ArcGIS 3.1+. However, we have noticed one major regression.  Keypresses are being eaten by ArcGIS Pro 3.1+.  So, if a user tries to rename a node in one of our docking windows and starts typing, not all the letters will be typed.  If I type the alphabet a-z, only the letters "efghiklrt" are typed into the node's label.  All other letters are skipped/ignored. This behavior works 100% in ArcGIS Pro 2.x.  It does NOT work in ArcGIS Pro 3.x. I have attached two samples.  AGPEatenKeysAddIn.zip is for ArcGIS Pro 3.x.  AGPEatenKeysAppAGP2.zip is for AGP2.  All you need to do is extract, open the solution, build and run in the appropriate version of AGP.  There is a button on the Add In tab that will open the dock pane that is in the add-in.  Just rename any node in the tree provided and start typing.  Note that in the AGP2 sample F2 won't rename, and you'll need to single click the node with the mouse to start editing node.  F2 is implemented in the AGP3 sample. We are not in the position to switch our controls to WPF.  It was already an 18-month effort to target net6 and it would take far longer to start using WPF in any capacity.  Using WPF controls is *NOT* an option. Any suggestions for a workaround are appreciated and will be considered.  I am really hoping an ESRI developer will dig into this issue.  Maybe they can find a work around but better is to fix the issue since it is a regression. If you have any questions or need more information, please ask. TIA, Kris ... View more

Hello, Our application has about 27 dock panes that can be opened by our users.   These are typically grouped together where they relate to each other so they are easier to find when open. In our daml file, we are using dock="group" and dockWith="id" where "id" is the id of our dockPane.  However, the dock panes open docked to the left by default.   Questions: Can we open the dock pane floating by default but also grouped together so that common panes are tabbed but floating?  For example, I have dock panes "Dock1", "Dock2", and "Dock3".  I want them floating but docked together when they are initially opened.  If I use dock="group" they get docked together but they are docked to the left by default.  If I set dock="float" they open floating but not docked together even though dockWith is set. Is there a way to reset the layout that was saved in a previous session of AGP so on the next open (or even in the current session), the default settings of the dock pane are used from the daml file? It feels like this used to work but regressed in AGP 3.x but I can't say for sure. TIA, Kris ... View more

Hello, My team is in the process of upgrading our configuration from AGP 2.9 to AGP 3.1.  During our initial testing, we found that our delete behavior is not working by causing an invalid operation on the EditOperation. We tracked down the issue to the change in behavior for the EventToken property on the EditOperation class. This is a direct copy of the summary comments for the property: // // Summary: // Provides a way for calling code to identify a particular EditOperation within // a subsequent EditEvent. Setting an EventToken in an EditOperation is optional // - by default it is null. If set to a non-null object, the EditOperation is subsequently // successful, and, an EditEvent is published, then the EventToken object set here, // will be available from the corresponding ArcGIS.Desktop.Editing.Events.EditCompletedEventArgs.EventToken. However, there was an apparent bug in AGP 2.9.  In 2.9, when creating a chained edit operation, the parent was not being set to the internal private field.  As a result, the EditOperation, if it was the parent or the chained instance, held on to its own EventToken instance.  Look at the EventToken property here: public object EventToken { get { if (_parentOperation == null) { return _eventToken; } return _parentOperation.EventToken; } set { ThrowIfReentrant(); _eventToken = value; } } In AGP 2.x, the _parentOperation field was always null.  Therefore, when the EventToken was assigned on a ChainedEditOperation instance, it would hold onto its own EventToken and the getter would always return that instance, not the parent's instance. In AGP 3.x, this changed.  You apparently "fixed" this bug.  Even though you can assign the EventToken to a ChainedEditOperation, it is only returned IF the parent is null.  But the parent is NEVER null for a ChainedEditOperation. Why do you have the parent null check in the first place?  Based on the comments, it seems like you should be able to assign the EventToken independently of the parent, which is what we do in our code.  We use the EventToken in some very important use cases.  Working around this fix is difficult (not impossible, but difficult). Would it be possible to revert the fix in some way to bring back the original behavior? Perhaps add an overload for the CreateChainedEditOperation where you can pass in the EventToken you want to use?  Though it may not be possible to know at the time the method is called what to provide.  Or maybe instead, the overload takes a Boolean to flag to use a local instance instead of the parent EditOperation's instance of the EventToken. The point I am trying to make is that this was a VERY subtle change in behavior and the only reason I figured it out is because I am very good at debugging my own code.  I also compared the call stack between the use of AGP 3.x SDK AGP 2.x SDK (which is no easy feat). I am hoping someone from ESRI can respond to this with details on what is truly expected with the use of the EventToken.  It really makes you wonder what other subtle changes might be in the SDK that could cause unexpected behavioral changes. Kris Culin ... View more