prevent Last Copy Of Group Deleted error

[e.arendsRMCF7]

Hi,

Is there a way to prevent Revit from deleting a group from the project when LastCopyOfGroupDeleted is triggered?

I have one attached detail group that is removed from the project when deleted, both when using the Attached Detail Group Placement dialog and the delete action. Others do not get this error, even if the last copy is removed.

A work-around is changing the type of the detail group to another attached detail group, then deleting that one. Obviously this won't work if there is only 1 detail group attached to the model group.

What is the difference between the attached detail groups that are deleted, and those that aren't?

How can I prevent it from happening?

Thanks!

[psmGBPVX]

Not sure if I'm interpreting the problem completely. 

But attached detail groups that have a model instance existing exist within the model group, where as if its not attached it has nothing hosting it (?) taking a stab there.

Is there a reason you don't just use a detail family instead of a detail group?

If you copied all of your notation across to a generic detail family you could delete/place as you wish and it wouldn't disappear from your project until you actively delete it or purge the model.

[e.arendsRMCF7]

@psmGBPVX wrote:

Not sure if I'm interpreting the problem completely. 

But attached detail groups that have a model instance existing exist within the model group, where as if its not attached it has nothing hosting it (?) taking a stab there.

---

Yes, it's a group that contains tags for windows and such, as well as dimensions.

We're not using families, because as far as I know, the tags need to be in an attached detail group. We have many instances of the same group, so this seems to be the easiest way to add the dimensions.

I'll look into the detail families, but my colleagues are not very keen on them.

Thanks

[kadmonkee]

hopefully this helps

from this link LastCopyOfGroupDeleted 

There are three types of groups in Revit; Model Group, Detail Group, and Attached Detail Group. All are created using the NewGroup() method. The created Group's type depends on the Elements passed.

• If no detail Element is passed, a Model Group is created.
• If all Elements are detail elements, then a Detail Group is created.
• If both types of Elements are included, a Model Group that contains an Attached Detail Group is created and returned.

Note: When elements are grouped, they can be deleted from the project.

• When a model element in a model group is deleted, it is still visible when the mouse cursor hovers over or clicks the group, even if the application returns Succeeded to the UI. In fact, the model element is deleted and you cannot select or access that element.
• When the last member of a group instance is deleted, excluded, or removed from the project, the model group instance is deleted.

When elements are grouped, they cannot be moved or rotated. If you perform these operations on the grouped elements, nothing happens to the elements, though the Move() or Rotate() method returns true.

You cannot group dimensions and tags without grouping the elements they reference. If you do, the API call will fail.

You can group dimensions and tags that refer to model elements in a model group. The dimensions and tags are added to an attached detail group. The attached detail group cannot be moved, copied, rotated, arrayed, or mirrored without doing the same to the parent group.

try removing the annotative tags dimensions etc. to create a MODEL group then apply dimensions and tags as needed. this can be done with an enlarged plan of that grouped area

[psmGBPVX]

Right, ok yeah tags etc don't really work hosted in a detail family.

There are workarounds you could do with either phases or worksets where you have a group that exist in perpetuity in the background on a phase/set that is turned off, but i don't really like advising that kind of thing as its not very neat.

[HFA.Ben.Steinert]

Running into this myself with Revit 2021 as well and I am not seeing a solution to it. For the majority of views and their respective attached detail groups this delete warning is not triggered when turning the attached detail group off, but for a few the warning comes up and we lose the persistence of the attached detail group despite the host model group remaining present in the project.

This error pretty much destroys the usefulness of attached detail groups. I will keep digging in the project and see if the behavior is linked to a specific element that I am adding to the attached detail group.

I have spent a lot of time developing some dynamo tools that rely upon model groups and attached detail groups remaining persistent in a project even when they are not placed, so a fix or workaround would be great.

[jvpantin2]

Hi,

AFAIK the project browser always keep a "non placed" instance of groups despite all instances in model were deleted, in fact, you know when there is no instance of a group or family in model by selecting it in the project browser, right-click and then "select all instances in model": if there is only one (1) indicated but greyed out in Properties palette means there is no instance in model but you can create one right-clicking again. I suggest three inelegant solutions: 1) pin a group instance; 2) create a "container" phase and throw; 3) save group andf keep it for future loads.

Hope this will help,

[HFA.Ben.Steinert]

Thanks for the quick response. That is the expected behavior that I want. Making the dynamo tools I had to become familiar with the difference of GroupType in the Revit API as that is exactly what I expect to persist when an instance of a Group or Attached Detail Group is removed from all views...yet this warning is coming up and it proceeds to completely remove the types from the project on it's own. I have seen it do so a few times even without the warning...but I believe I have narrowed it down to a dimension reference that it is struggling with.

It also seems to be mixing with the warning "can't make change to group with more than one instance" when editing the Attached Detail Group. This also seems to lead to inability to place the compromised Attached Detail Group on any other instance of the associated group. Maybe this is just Revit's way of weeding out corrupt data as per usual

I am going to try going back into a previous version of my file and see if I can track all of the errors back to dimension references.

[HFA.Ben.Steinert]

Sorry to keep dragging this on, but I may have found a way to "reset" the GroupType and also a way to identify when a Model Group is exhibiting this corrupt behavior.

To identify a bad model group type:
In the project browser, if you right click on one of the Model Group types and then select "Edit" from the list that pops up, it will open that group in a new viewport, and what seems to be the equivalent of a family editor but for model groups. For the model groups that were not working correctly in my case, this view opened almost instantly with only a single level and no model elements! With a model group that is working correctly it should not be instant, you should see the status bar "Pasting" model elements from the model group into this new view.

To reset the bad model group:
Place a new instance of the model group within the project, anywhere is fine. With the newly placed instance selected, click "Edit Group", then click "Remove" and remove one model item, then click "Finish". The model group type should be reset at this point, but you can go through those steps again to add the item back to the group so that no work is lost. You can also verify that the type has been reset by going through the identify steps above again and seeing all of the elements as expected.

Once I reset the problem model group type, the "last copy of group deleted" error did not appear when the attached detail groups were turned off in all views, and I am now able to recall them on demand as needed without any untidy steps.

Hope this helps someone else out there, and I will be back if I encounter any groups that this does not work on.