About IDs on deletion

[Anonymous]

Hi, everyone.

I have questions and problems. I have a Dictionary mapping uniqueIDs to area measures, it is initialized when a document is opened, and updated when a new element is added or modified.

But I am really struggling to update it when a deletion is made, as the ElementId is returned, not the uniqueID.

I have tried to use ElementIDs then to identify my elements, as the program does only take into account the actual document, I believe this should be OK. But another problem appears now. Some ElementIDs seem to be modified at some point:

As you can see, the ElementID does not match, it seems to be modified (I am deleting the correct element in the project).

I've come across old posts (https://forums.autodesk.com/t5/revit-api-forum/get-uniqueid-of-deleted-element-within-dynamic-update...  and https://forums.autodesk.com/t5/revit-ideas/provide-more-information-about-deleted-element-ideally-a-... ) but they don't seem to be solved yet.

Thus, my questions are the following:

• Do UniqueIDs change along time?
• Is there now any way to retrieve the UniqueID on deletion?
• The difference of 2 in the IDs means anything at all?
• Am I being silly and this should be trivial? 😂

Thanks in advanced!

Jose Antonio Lorencio Abril

[jeremy_tammik]

Thank you for your perfectly valid and interesting question.

Unfortunately, you are not being silly in any way at all and this is a real challenge.

You can be notified when an element is deleted, for instance by subscribing to the DocumentChanged event:

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

However, when you are notified, the element is already gone and no information about it or its properties is accessible any more.

There is a wish list item to improve this situation in the Revit Idea Station: 

Provide more information about deleted element: Ideally a read-only copy.

https://forums.autodesk.com/t5/revit-ideas/provide-more-information-about-deleted-element-ideally-a-...

I suggest that you and all other interested parties vote for it to raise its priority.

[RPTHOMAS108 · Accepted solution]

If you use ExtensibleStorage to store the ElementIds such stored ids will become invalid (-1) when they are deleted from the document.

If you store a dictionary of String, ElementId (with string being the UID) then during DocumentChanged event you can read the extensible storage dictionary to find dictionary values of (-1) and get the associated string UID keys. I would not recommend using ElementId for key since you can't have multiple keys of -1. That way around I assume the entries are removed when elements are deleted.

If you don't have a very large number of elements to track it can be done this way. When storing dictionary to extensible storage you would first get the existing from EStorage, remove (-1) values from last deletion, add new values (the elements you want to track future of) then write back to EStorage.

You can't write back to EStorage during document changed event and you'll have the previously deleted reported until the EStorage record is updated. You may be able to use IUpdater instead of DocumentChanged perhaps but I don't think it's an issue since you can ignore the deleted UIDs reported that have already been dealt with.

On the whole if you use extensible storage to store the data then it probably takes care of itself i.e. if you had data storage element with dictionary of ElementId, Entity for each element stored then the ones deleted I assume would disappear from the dictionary since you can't have multiple keys the same (keys of -1). There is then also the more straightforward way having the data stored on the element deleted i.e. why not store the area on the element the area is associated with.

[jeremy_tammik]

Thank you for the good explanation.

If you implement a dictionary mapping an integer key with a value determined by ElementId.IntegerValue to a pair of ElementId + UniqueId, you should be able to determine both the original element id integer value and the associated unique id by searching for the -1 ElementId values.

The DMU updater framework is indeed designed to ensure that such mappings can be kept up to date and intact even including undo and redo operations and other complex interactions by ensuring that the triggering operation and the resulting event handler actions are wrapped in the same transaction.

[Anonymous]

Thanks for the idea, I will try it!

The problem I see is you need to loop over every element, so that feels pretty unoptimal, even more if we assume that when we delete something, it is usually just one element.

I definitely think some feature should be added, as the commented post asks.

Cheers!