DocumentChanged reports no ids after cancelling assembly edit

[BardiaJahan]

I know there has been many discussions about DocumentChanged eventhandler and Dynamic Model Updater. This is another observation and I thought it would be useful to share:

I want to keep track of changes made to AssemblyInstances and save the changes to an external database - no internal changes - so I am registering a handler to DocumentChanged event and I am not working with Dynamic Model Updater. The advantage is it is raised with Undo and Redo too.

Everything works fine except when the user enters the Edit Assembly mode. In that mode, making the changes raises the handler and again everything goes as expected but when the user cancels and exit the edit assembly mode,event handler is raised but GetModifiedElementIds(), GetDeletedElementIds() and GetAddedElementIds() does not reflect any ElementIds.

As the workaround, I am tracking the transactions too by using GetTransactionNames(). I am retrieving all changes during 'Assembly Edit' transaction but save them to the external database only after making sure the edit was not cancelled by the user.

[jeremytammik]

Thank you very much for sharing this important observation.

Could you provide a complete minimal reproducible case with exact steps for me to pass on to the development team?

http://thebuildingcoder.typepad.com/blog/about-the-author.html#1b

Thank you!

Cheers,

Jeremy

[BardiaJahan]

Well, let's say just simply register to OnDocChanged event handler when the external command is run. And in the event handler just retrieve the number of elementids that are modified, added and deleted. 

After registering to the event by running the command any changes made to the document results in a dialog showing info regarding elements. While entering the Assembly Edit mode it still tracks and shows the correct info even when the user Undo or Redo. However, in Assembly Edit mode when the user cancels edit the event handler does not retrieve any ElementId.

static void OnDocChanged(Object sender, Autodesk.Revit.DB.Events.DocumentChangedEventArgs e)
		{
			string s = "";

			ICollection<ElementId> modified = e.GetModifiedElementIds();
			ICollection<ElementId> deleted = e.GetDeletedElementIds();
			ICollection<ElementId> added = e.GetAddedElementIds();

			s += string.Format("No. Elements Modified: {0} \n\r", modified.Count);
			s += string.Format("No. Elements Added: {0} \n\r", added.Count);
			s += string.Format("No. Elements Deleted: {0} \n\r", deleted.Count);

			TaskDialog.Show("OnDocChanged", s);
		}

public Result Execute(ExternalCommandData commandData, ref string message, ElementSet elements)
		{

                        commandData.Application.Application.DocumentChanged += new EventHandler<Autodesk.Revit.DB.Events.DocumentChangedEventArgs>(OnDocChanged);

			return Result.Succeeded;
                }

 P.S.: Of course the code needs to have a mechanism to unregister the handler which I did not include.

[jeremytammik · Accepted solution]

Thank you for your description.

I logged the issue REVIT-127211 [DocumentChanged reports no ids after cancelling assembly edit -- 13917399]

 with our development team for this on your behalf as it requires further exploration and possibly a modification to our software. Please make a note of this number for future reference.

You are welcome to request an update on the status of this issue or to provide additional information on it at any time quoting this change request number.

This issue is important to me. What can I do to help?

This issue needs to be assessed by our engineering team and prioritised against all other outstanding change requests. Any information that you can provide to influence this assessment will help. Please provide the following where possible:

• Impact on your application and/or your development.
• The number of users affected.
• The potential revenue impact to you.
• The potential revenue impact to Autodesk.
• Realistic timescale over which a fix would help you.
• In the case of a request for a new feature or a feature enhancement, please also provide detailed Use cases for the workflows that this change would address.

This information is extremely important. Our engineering team have limited resources, and so must focus their efforts on the highest impact items. We do understand that this will cause you delays and affect your development planning, and we appreciate your cooperation and patience.

Best regards,

Jeremy

[jeremytammik]

Dear BardiaJahan,

You ask why you were notified that the associated ADN case 13917399 [DocumentChanged reports no ids after cancelling assembly edit] was closed.

Whether the ADN case is open or closed makes no difference as long as we are aware of its existence and case number.

You can reopen, update and add any new information you wish to it at any time you like regardless.

I much prefer communicating all non-confidential information with you over the public forum, though, so that others can share and contribute as well.

Furthermore, the status of the ADN case in no way affects the internal development issue REVIT-127211 [DocumentChanged reports no ids after cancelling assembly edit -- 13917399]. The development team only care about the latter. I have not had any feedback from them on it yet, though. I will let you know as soon as I hear anything.

Best regards,

Jeremy

[BardiaJahan]

Thanks Jeremy

[jeremytammik]

Dear BardiaJahan,

The development team analysed the internal issue REVIT-127211 [DocumentChanged reports no ids after cancelling assembly edit -- 13917399] that I raised for you and say:

It is by design when TransactionRolledBack or TransactionGroupRolledBack - no change was actually accepted at end.

The DocumentChanged event report no ids in such cases. Is the requirement to retrieve the temporary changes before the rollback? If so we may need to design a new mechanism.

DocumentChanged is designed to only report actual changes that were accepted once the transaction or transaction group ended.

That is pretty evident, actually, and I am sorry that I did not think of telling you so myself before raising the issue with the development team.

I hope this clarifies.

If you would wish such an enhancement to be made for future versions, please raise a wish list item for it in the Revit Idea station.

Thank you!

Best regards,

Jeremy

[RPTHOMAS108]

Hello Jeremy

Something still seems a bit inconsistent here to me.

If you are in assembly edit mode then why does the document changed event occur during that editing mode if changes are considered temporary until confirmed at end of edit mode? How do you roll back a transaction once you are outside of the transaction scope? By the logic described wouldn't you expect the document changed event to occur only after exiting the assembly edit mode (if you accept the changes). If it's a temporary change then it isn't a document change and so the event should not occur during the edit mode.

I think @BardiaJahan issue was that he was tracking IDs externally and the firing of the DocumentChanged event during assembly edit mode was causing him false positives. Would have been remedied if it only fired after the edit mode completed as then he would have had an actual list of elements changed if any.

Regards

Richard

[BardiaJahan]

@RPTHOMAS108 You are totally right! My issue was that it was returning changes in the assembly edit but as soon as the user cancels the edit mode, it returns nothing! I was expecting it to return Undo's of those transactions though. I am assuming it behaves the same in other edit modes and this makes it not quite easy to track the changes made to the document.

@jeremytammik So is it like each individual Transaction commit() but the TransactionGroup rolls back? or something else is happening?