Select to view content in your preferred language

RowChangedEventArgs

2016
11
Jump to solution
06-12-2018 10:01 AM
JeffMatson
Frequent Contributor

In ArcPro 2.1 there was an Operation object available in the args:

private void OnRowChanged(ArcGIS.Desktop.Editing.Events.RowChangedEventArgs args)
{
   QueuedTask.Run(() =>
   {
       EditOperation eo = args.Operation;

//blah blah blah
//more awesome code
//blah blah blah

});

}

I don't see it any longer in ArcPro 2.2 - anyone know if this is coming back?

Tags (1)
0 Kudos
1 Solution

Accepted Solutions
by Anonymous User
Not applicable

Hi Jeff,

It was pushed back to 2.3

View solution in original post

0 Kudos
11 Replies
by Anonymous User
Not applicable

Hi Jeff,

It wasn't publicly exposed in 2.1 but were looking to put it in for a future release, so we can all write more awesome code.

0 Kudos
JeffMatson
Frequent Contributor

I feel like we've had this conversation before 

Any idea *when* this will be available?  Also how about Undo/Redo events?

Thanks,

Jeff

0 Kudos
by Anonymous User
Not applicable

Hi Jeff,

It was pushed back to 2.3

0 Kudos
StuartBricker
Emerging Contributor

Following up to this, it appears that the RowChangedEventArgs have a Guid property. Is it possible to obtain a reference to the underlying Edit Operation via the Guid property?

0 Kudos
by Anonymous User
Not applicable

Nope. Although it is the GUID of the calling editoperation, there's no way to hydrate it.

The GUID is used here to prevent reentrancy scenarios.

    Guid _lastEdit = Guid.Empty;

    private void onRowChangedEvent(RowChangedEventArgs obj)
    {
      if (_lastEdit != obj.Guid)
      {
        obj.CancelEdit("Change Event\nAllow Edit?", true);
        _lastEdit = obj.Guid;
      }
    }
0 Kudos
StuartBricker
Emerging Contributor

Hello Sean,

I was super excited to see that 2.3 is out in the hopes that this would be addressed. But unfortunately it appears that this functionality was not included in 2.3. Do you have any further word on this functionality? My intended use is pretty much identical to the original question:

eventToken = ArcGIS.Desktop.Editing.Events.RowCreatedEvent.Subscribe(pointPlaced, addressFeatureClass);

private void pointPlaced(ArcGIS.Desktop.Editing.Events.RowChangedEventArgs args)
{
   QueuedTask.Run(() =>
   {
       EditOperation op = args.Operation; // waiting for v2.3 to implement
       // do awesome stuff to newly created address point
   }
}

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍
0 Kudos
by Anonymous User
Not applicable

Hi Stuart,

2.4... for real this time.

I've been testing it this afternoon.

StuartBricker
Emerging Contributor

Cool. Thanks Sean for all of your hard work. Much appreciated.

0 Kudos
StuartBricker
Emerging Contributor

Hello Sean,

I've had a chance to play around with the newly added .Operation property. There is one thing that I noticed that I wanted to ask you about though. Whenever I execute the edit operation that is passed to the event handler by the RowChangedEventArgs, it throws a System.NotSupportedException. If I catch the exception, and just do nothing with it, the edit operation will sucessfully complete. In the following code sample, It will sucessfully write "TEST WRITE" to "TESTFIELD", and show the error message in a dialog box.

        void CreateHandler(RowChangedEventArgs args)
        {
            QueuedTask.Run(async () => 
            {
                Debug.WriteLine("Create Feature Event Handler");
                try
                {
                    EditOperation op = args.Operation;
                    op.Modify(args.Row, "TESTFIELD", "TEST WRITE");
                    await op.ExecuteAsync();
                }
                catch (NotSupportedException ex)
                {
                    ArcGIS.Desktop.Framework.Dialogs.MessageBox.Show(ex.ToString(), "Not supported Exception:");
                }
                catch (Exception ex)
                {
                    ArcGIS.Desktop.Framework.Dialogs.MessageBox.Show(ex.ToString(), "Exception:");
                }
            });
        }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

and the subsequent error dialog:

If I simply comment out the message box, the edit completes seamlessly from the user's perspective, but Visual Studio will push: "Exception thrown: 'System.NotSupportedException' in mscorlib.dll" to the debug console. Any thoughts on what is causing this?

0 Kudos