bug(revit): CNX-8730 deletes existing objects in a subtransaction during receive #3209
Conversation
clairekuang
changed the title
There was a problem hiding this comment.
Changes seem legit but I'll defer to @connorivy since my knowledge of the use of TransactionManager is limited.
| @@ -333,6 +337,7 @@ void ConvertNestedElements(Base @base, ApplicationObject appObj, bool receiveDir | |||
| if (index % 50 == 0) | |||
| { | |||
| transactionManager.Commit(); | |||
| transactionManager.Start(); | |||
There was a problem hiding this comment.
Hey @clairekuang your changes look good. One of the reasons that this issue was happening is because this loop was exiting when index % 50 == 0 (aka it was the 0th object) which was leaving the transaction in a closed state. That was my mistake in originally making this, the transaction should continually be open until we call "Finish" because anyone looking at it would assume that it is open until that point.
It is still good to wrap the object deleting in a subtransaction like you did, but this line is necessary so that this doesn't happen with some other method in the future
clairekuang
deleted the
CNX-8730-DirectShapes-created-from-SketchUp-Mapper-not-updating
branch
Description & motivation
When receiving in Revit in update mode, always deletes existing objects in a subtransaction. This fixes a bug where in certain conditions, attempts to delete existing objects are made without any active transaction.
This bug turned out to be completely unrelated to Sketchup direct shape mappings, but direct shapes are one of few objects that are properly "updated" (an existing direct shape object's shape is modified in update mode, vs the existing object being deleted and a new ds being created).
The following reproduction steps create the "failed update" behavior:
While my changes appear to fix the failed updating behavior described above, I'd like @connorivy to take a look at the proposed changes because it's still unclear to me why no active transaction existed (my guess is that passing the transaction manager to the converter, editing the direct shape in the converter closed the transaction, and therefore no open transaction was available when the connector attempts to delete the existing object ). There may be a more robust way to handle transactions due to the differences in direct shape editing in the converter compared to most other conversion routines.
To-do before merge: