Moribund Elements

[Dale.Bartlett]

We recently had a case with a corrupt element that could not be purged or deleted within Revit. This is the entry in the journal: "The following untracked moribund element(s) have been discovered in the newly opened document:". So far it appears that I was able to delete the element via the api. My question is: Can "moribund" (near-death) elements be found in the database rather than via the journal? Even if they are rare, I would much rather a QA check to preempt problems. Thanks again, Dale

[arnostlobel · Accepted solution]

Hello Dale!

It is very unlikely that we will come up with an API to access moribund elements. In fact, we would like our users from both the UI and API camps to know nothing about them at all. And, ideally, it would be so if there were no bugs in Revit. Unfortunately, as it happens there are a few bugs remaining in Revit (a joke ;-), thus it is apparently possible, now and then, for users to encounter these moribunds that escaped their destiny of certain death at the end of a transaction. For deletion is the only future those elements should face. Once marked a moribund, an element is presumed dead and awaiting its actual termination. The fact that is not actually deleted yet allows us to examine it if some other (related) elements feel compelled to do so (within the same transaction), but no changes to moribunds should be done any more. For all practical operations, a moribund is as good as dead. Technically, if a moribund evades its deletion, it should be considered a corruption of the containing document. I would expect it to be a minor corruption in most cases; something the user can happily live without likely not worrying and experiencing problems. That, naturally, depends on the nature of the element, however.

The main point I am trying to convey here is that moribund elements are meant to be used and accessed only by us, Revit internal developers.

Thank you

[Dale.Bartlett]

Thanks Arnošt,

Your information was very helpful. In our case it was a serious problem: "The BIG problem with this is that we cannot use Clarity with these files that have the corrupt elements, as the permissions cannot be set for the corrupt elements". It also resulted in Revit crashes. Our deletion via the API has resolved the problem. Regards, Dale

[arnostlobel]

Hello Dale,

I am sorry for your trouble. Like I said, there are bugs, and sometime it happens that moribund elements survive a transaction. If it gives you repeatedly trouble, I can only suggests contacting our customer support or and ADN representative, for we would need to have the file or at least the journal, ideally both. These bugs are of such nature that we cannot figure what exactly went wrong unless we know at least the name of the class of the element that got moribund and survived. If we can replay the journal when it actually happen, meaning we be able to stop at the transaction when the moribund element (or elements) weren't deleted (it would give us a warning if we play it in our in-house environment), the bug would be as good as fixed. However, even knowing the name of the element class would be of a great value.

Thank you

[Dale.Bartlett]

This is all working well and has resolved our problem. As the function allows a user to type any number for an Element ID, it has been interesting that ElementId 0 = New Construction Phase, ElementId 1 = Project Phase Information, ElementId 2 = Lineweights, etc. Entering these numbers and proceeding obviously brings on a few tears. My question is: are the fixed, internal, application-centric ElementIds listed somewhere? Is it possible to check for system ElementIds against user-created ElementIds? Thanks again, Dale

[arnostlobel]

Hello Dave!

I do not advise you to depend on seemingly fixed element Ids in your applications. They may appear constant, but they really aren't. Revit assigns consecutive integers to elements as they get created. The numbers may look like constants even between Revit sessions, but any change to our code may shuffle the order in which elements get created (and that is virtually certain to happen between even minor version updates.)

[Dale.Bartlett]

Thanks Arnost,

I understand the principle of not relying on the Element ID to be fixed. Saying that, it looked like ElementId 0 = New Construction Phase, ElementId 1 = Project Phase Information, ElementId 2 = Lineweights, etc. were definitely Revit internal IDs.

More specifically, is it possible to check for system ElementIds against user-created ElementIds? 

Regards,

Dale

[arnostlobel]

Dale,

the element Ids you referred to aren't of any internal elements. The fact they have the values as they do is just a pure coincidence. And like I said, they may be completely reordered in next release, even in a minor, incremental one.

There indeed are some internal elements in Revit, but their values are out of the standard range regular elements can ever get. You cannot get those elements via the API, and even if you somehow guess their Ids Revit will return NULL when you ask for the actual element. Naturally, we have very good reasons for this protection. Internal elements are not observable and must be handled in very specific ways. There are essential to Revit functioning properly (in each document). Also, all of those internal elements do not have corresponding, public API element classes, thus an API developer cannot do anything with them anyway (besides possibly deleting them and/or copying them, which is not allowed anyway.)

Thank you