Updating a View Parameter After a Viewport is Removed from a Sheet

[BIMTeam]

I'm currently working on a Revit add-in where I need to update a parameter (specifically the "User Name" parameter) of a View after its associated Viewport is removed from a sheet.

Problem:

I have set up an updater that triggers when elements are deleted using Element.GetChangeTypeElementDeletion() in the UpdaterRegistry. However, when a Viewport is deleted (e.g., a view is removed from a sheet), the ElementId returned by the UpdaterData.GetDeletedElementIds() method no longer points to a valid Element. As a result, I'm unable to retrieve the ViewId or any other information related to the View that was associated with the deleted Viewport.

What I've Tried:

• Using var deletedIds = data.GetDeletedElementIds();: This method captures the IDs of the deleted elements but since the ElementId refers to a Viewport that has already been deleted, it's not possible to access the ViewId or update any parameters of the View after deletion.

• Sub-Transaction Rollback: I attempted to start a sub-transaction before the deletion, retrieve the ViewId, and then roll back the sub-transaction to "undo" the deletion temporarily. Unfortunately, this approach did not work as expected, as it failed to capture the ViewId in a usable state before the deletion was finalized.

Question:

Is there a reliable method or best practice for updating a View parameter after its associated Viewport has been deleted from a sheet? Specifically, how can I capture the necessary information (like the ViewId) before the deletion is finalized so that I can update the "User Name" parameter after the deletion?

I would greatly appreciate any guidance or examples from those who have dealt with similar scenarios. Thanks in advance for your help!

[BIMTeam]

I'm currently working on a Revit add-in where I need to update a parameter (specifically the "User Name" parameter) of a View after its associated Viewport is removed from a sheet.

Problem:

I have set up an updater that triggers when elements are deleted using Element.GetChangeTypeElementDeletion() in the UpdaterRegistry. However, when a Viewport is deleted (e.g., a view is removed from a sheet), the ElementId returned by the UpdaterData.GetDeletedElementIds() method no longer points to a valid Element. As a result, I'm unable to retrieve the ViewId or any other information related to the View that was associated with the deleted Viewport.

What I've Tried:

• Using var deletedIds = data.GetDeletedElementIds();: This method captures the IDs of the deleted elements but since the ElementId refers to a Viewport that has already been deleted, it's not possible to access the ViewId or update any parameters of the View after deletion.

• Sub-Transaction Rollback: I attempted to start a sub-transaction before the deletion, retrieve the ViewId, and then roll back the sub-transaction to "undo" the deletion temporarily. Unfortunately, this approach did not work as expected, as it failed to capture the ViewId in a usable state before the deletion was finalized.

Question:

Is there a reliable method or best practice for updating a View parameter after its associated Viewport has been deleted from a sheet? Specifically, how can I capture the necessary information (like the ViewId) before the deletion is finalized so that I can update the "User Name" parameter after the deletion?

I would greatly appreciate any guidance or examples from those who have dealt with similar scenarios. Thanks in advance for your help!

[jeremy_tammik]

Unfortunately, you have encountered a well-known and deplored problem with DMU reactions to deleted elements: as soon as the element has been deleted, its data is gone and cannot be accessed. Currently, the only workaround I can think of is to store the information (that you wish to access after the deletion) elsewhere as well, beforehand, so that it remains accessible after the element has been deleted.

[jeremy_tammik]

Unfortunately, you have encountered a well-known and deplored problem with DMU reactions to deleted elements: as soon as the element has been deleted, its data is gone and cannot be accessed. Currently, the only workaround I can think of is to store the information (that you wish to access after the deletion) elsewhere as well, beforehand, so that it remains accessible after the element has been deleted.

[BIMTeam · Accepted solution]

Hi Jeremy,

Thank you for your guidance on this issue. With your advice in mind, I’ve been able to successfully implement a solution for updating the "User Name" parameter of a view after its associated viewport is removed from a sheet.

Problem Recap:

The main challenge was that when a viewport is deleted, Revit's GetChangeTypeElementDeletion() trigger fires after the element is already gone, making it impossible to retrieve the necessary ViewId to update the associated view’s parameters. Additionally, simply relying on ViewActivated to detect active sheet views wasn't sufficient because actions taken within the same active view (like adding and then removing a viewport) wouldn't trigger the necessary updates.

Solution:

Here’s how we achieved it:

1. Order of Operations:

   • We process deletions and modifications first, ensuring that any necessary updates to the "User Name" parameter are handled before collecting and storing the remaining Viewport data.

2. Deferred Data Collection:

   • After handling deletions and modifications, we collect and store all Viewport element IDs and their associated ViewIds for the active sheet view. This ensures that the stored data reflects the current state of the sheet, including any recently removed or added viewports.

3. Active View Check:

   • We added a check to ensure that the current active view is a sheet (ViewType.DrawingSheet). This ensures that our data collection logic only applies to sheet views, preventing unnecessary processing for other view types.

[BIMTeam · Accepted solution]

Hi Jeremy,

Thank you for your guidance on this issue. With your advice in mind, I’ve been able to successfully implement a solution for updating the "User Name" parameter of a view after its associated viewport is removed from a sheet.

Problem Recap:

The main challenge was that when a viewport is deleted, Revit's GetChangeTypeElementDeletion() trigger fires after the element is already gone, making it impossible to retrieve the necessary ViewId to update the associated view’s parameters. Additionally, simply relying on ViewActivated to detect active sheet views wasn't sufficient because actions taken within the same active view (like adding and then removing a viewport) wouldn't trigger the necessary updates.

Solution:

Here’s how we achieved it:

1. Order of Operations:

   • We process deletions and modifications first, ensuring that any necessary updates to the "User Name" parameter are handled before collecting and storing the remaining Viewport data.

2. Deferred Data Collection:

   • After handling deletions and modifications, we collect and store all Viewport element IDs and their associated ViewIds for the active sheet view. This ensures that the stored data reflects the current state of the sheet, including any recently removed or added viewports.

3. Active View Check:

   • We added a check to ensure that the current active view is a sheet (ViewType.DrawingSheet). This ensures that our data collection logic only applies to sheet views, preventing unnecessary processing for other view types.