IUpdater for ElementAddition fires before floor placement is complete

[sroswurm4GJQU]

I've worked with IUpdaters in Revit 2020 fairly frequently for a number of different elements, but I'm seeing some behavior with floors that seems less than ideal.  My testing centers around either one of the following triggers:

UpdaterRegistry.AddTrigger(myFloorCreatedUpdater.GetUpdaterId(), 
                           new ElementClassFilter(typeof(Floor)), 
                           Element.GetChangeTypeElementAddition());

OR

UpdaterRegistry.AddTrigger(myFloorCreatedUpdater.GetUpdaterId(), 
                           new ElementCategoryFilter(BuiltInCategory.OST_Floors), 
                           Element.GetChangeTypeElementAddition());

Based on these triggers, the associated IUpdater actually fires before a new floor placement is complete.  Instead of the IUpdater Execute() firing after the you draw the floor and "Finish Edit Mode", it fires as soon as you enter Edit Mode.  Then when you "Finish Edit Mode", it also triggers the IUpdater for 

Element.GetChangeTypeGeometry()

This behavior seems problematic for several reasons: 

- First of all, Floor Edit Mode can be cancelled without creation of a floor, meaning that the ElementId captured by the UpdaterData was not actually created in the Document. 

- In addition, it means that virtually all usable information about the floor is meaningless at the moment that the IUpdater is fired.  Geometry cannot be extracted because the floor boundary has not yet been drawn.  And the floor type may be changed before finishing Edit Mode, so the CompoundStructure information for the floor cannot be trusted.

- For instances where the developer finds it necessary to distinguish between "new floor created" versus "existing floor modified", it is problematic that the floor creation ALSO triggers Element.GetChangeTypeGeometry()

Hypothetically, you could accomplish some things by moving your logic to the change updater instead of the addition updater, but this will leave you with some headache if you need to distinguish between new and existing floors.  Wouldn't this mean the the addition updater is essentially useless for this purpose?

I'd love to hear any thoughts that everyone has on this.  Is this the intended and expected behavior for IUpdaters that are triggered by floor creation?  Has anyone else experienced difficulty with this behavior?

@jeremytammik 

@Revitalizer 

@RPTHOMAS108 

@FAIR59 

[jeremy_tammik]

One small comment on this: I believe all updaters are always triggered before the operation is completed. This must be so, because the updater allows the add-in to add new input to the open transaction before closing it, and the operation is never complete until the transaction is committed and closed. I am sorry that this does not help much to answer your question, and possibly even raises new ones; still, the fact remains and should be kept in mind, I think.

[sroswurm4GJQU · Accepted solution]

Jeremy,

Thanks for your reply.  It definitely makes sense that the operation can't be completely finished before raising the trigger.  In this particular case unfortunately it seems that the breakdown of floor placement into multiple transactions makes it non-ideal for extracting usable information in the Execute() event of an updater triggered by addition.  I spent some time reviewing the UNDO queue and the journal file, and concluded that Revit actually commits a minimum of (4) individual transactions when a floor is created (see screenshot below):

1. Slab (i.e., creation of the floor element)
2. Boundary sketching (one transaction for each boundary segment placement or edit)
3. Finish sketch
4. Span direction

Apparently, the GetChangeTypeElementAddition() trigger is being fired in the very first transaction.  This breakdown also explains the two subsequent GetChangeTypeGeometry() triggers.  Presumably, they are associated with transactions 3. and 4.

So it appears that if you want to raise an IUpdater that lets you take specific actions in response to a floor creation, you have two choices:

1. Use the GetChangeTypeElementAddition() trigger, which lets you know a new floor has been created but tells you nothing about it, OR
2. Use the GetChangeTypeGeometry() trigger, which lets you access all geometry and other info about the changed floor, but does not allow you to know that the floor is newly created.

Most likely, my solution will be to rely of the GetChangeTypeGeometry() trigger and distinguish between new and existing floors using extensible data already implemented for other purposes.

[jeremy_tammik · Accepted solution]

Thank you for your careful and very useful analysis.

Please also note that if you wish to be notified about successfully completed Revit operations, the DocumentChanged event may be easier to use, though obviously read-only and much less versatile:

https://www.revitapidocs.com/2021.1/f7acc5b4-a1b4-12ca-802b-0ee78942589e.htm

Subscribe to the DocumentChanged event to be notified when Revit document has changed. This event is raised whenever a Revit transaction is either committed, undone or redone. This is a readonly event, designed to allow you to keep external data in synch with the state of the Revit database. To update the Revit database in response to changes in elements, use the IUpdater framework.