Announcements
Notice: Upload of PDF documents is currently unavailable across the Community due to an ongoing issue.

Why does GroupType.Groups contain ungrouped groups?

Why does GroupType.Groups contain ungrouped groups?

stefanome
Collaborator Collaborator
2,451 Views
10 Replies
Message 1 of 11

Why does GroupType.Groups contain ungrouped groups?

stefanome
Collaborator
Collaborator

The following code prints the same number twice:

 

var groupType = group.GroupType;
Debug.Print(groupType.Groups.Size.ToString());
group.UngroupMembers();
Debug.Print(groupType.Groups.Size.ToString());

 

Is this the correct behavior?

What do I need to do to make sure groupType.Groups always returns the correct GroupSet?

0 Likes
Accepted solutions (1)
2,452 Views
10 Replies
Replies (10)
Message 2 of 11

jeremy_tammik
Alumni
Alumni

Regenerate the model?

 

https://thebuildingcoder.typepad.com/blog/about-the-author.html#5.33

  

Jeremy Tammik Developer Advocacy and Support + The Building Coder + Autodesk Developer Network + ADN Open
Message 3 of 11

stefanome
Collaborator
Collaborator

Thanks for the tip, but I just tried and regenerating doesn't help.

It looks like I need to end and restart the transaction.

This code shows that GroupType.Groups still reports the ungrouped group after doc.Regenerate() and finally disappears after committing and restarting a new transaction. I tried to get a new reference to the GroupType, hoping that avoiding some caching would help, but it didn't:

tx.Start("Test 1");

var elementIds = new List<ElementId>
{
    Utils.CreateModelLine(new XYZ(0, 0, 0), new XYZ(1, 0, 0), doc).Id,
    Utils.CreateModelLine(new XYZ(0, 1, 0), new XYZ(1, 1, 0), doc).Id,
    Utils.CreateModelLine(new XYZ(0, 2, 0), new XYZ(1, 2, 0), doc).Id,
};
var group1 = doc.Create.NewGroup(elementIds);
var group2 = doc.Create.PlaceGroup(new XYZ(0, 5, 0), group1.GroupType);
var group3 = doc.Create.PlaceGroup(new XYZ(0, 10, 0), group1.GroupType);
Debug.Print(group1.GroupType.Groups.Size.ToString());

group2.UngroupMembers();
Debug.Print(group1.GroupType.Groups.Size.ToString());

doc.Regenerate();
Debug.Print(group1.GroupType.Groups.Size.ToString());

var groupType = new FilteredElementCollector(doc)
    .OfClass(typeof(GroupType))
    .Cast<GroupType>()
    .FirstOrDefault(gt => gt.Name == group1.GroupType.Name);
Debug.Print(groupType.Groups.Size.ToString());

tx.Commit();

tx.Start("Test 2");

Debug.Print(groupType.Groups.Size.ToString());
groupType = new FilteredElementCollector(doc)
    .OfClass(typeof(GroupType))
    .Cast<GroupType>()
    .FirstOrDefault(gt => gt.Name == group1.GroupType.Name);
Debug.Print(groupType.Groups.Size.ToString());

tx.Commit();

I tried using a SubTransaction, but didn't help.

At this point I do have a workaround, but I don't like to create transactions only because I can't rely on GroupType.Groups not reporting ungrouped groups.

Any advice?

0 Likes
Message 4 of 11

jeremy_tammik
Alumni
Alumni

Glad to hear you were able to discover a workaround.

 

Yes, committing the transaction is the next level up after regeneration.

 

Sorry I cannot offer any further suggestions, though.

  

Jeremy Tammik Developer Advocacy and Support + The Building Coder + Autodesk Developer Network + ADN Open
0 Likes
Message 5 of 11

GaryOrrMBI
Advisor
Advisor
Accepted solution

"I tried using a SubTransaction, but didn't help.

At this point I do have a workaround, but I don't like to create transactions only because I can't rely on GroupType.Groups not reporting ungrouped groups."

 

Just firing off the top of my head here but... instead of transactions and subtransactions you might try a transaction group with transactions within it... works just a little differently and perhaps that difference will be a little cleaner in the end...

 

Just my Two cents, take it for what it's worth 😉

 

-G

Gary J. Orr
GaryOrrMBI (MBI Companies 2014-Current)
aka (past user names):
Gary_J_Orr (GOMO Stuff 2008-2014);
OrrG (Forum Studio 2005-2008);
Gary J. Orr (LHB Inc 2002-2005);
Orr, Gary J. (Gossen Livingston 1997-2002)
0 Likes
Message 6 of 11

stefanome
Collaborator
Collaborator

Using a transaction group seem to be the best workaround. Here are the steps:

transactionGroup.Start
transaction.Start
group.UngroupMemebers
group.GroupType.Groups still contains the ungrouped group
transaction.Commit
group.GroupType.Groups does not contain the ungrouped group

Unfortunately such a workaround cannot be used in a generic case, because wrapping the group.UngroupMembers inside its own transaction only because any following groupType.Groups would return the wrong result is ugly, because it requires any caller to use a transaction group rather than a transaction.

0 Likes
Message 7 of 11

mhannonQ65N2
Collaborator
Collaborator

I recently had a somewhat similar problem (working w/ completely different objects though). It seems like in some cases the value returned by a Revit API object's property or method is always the same as when it was first obtained from the API, even after regenerating the model. To resolve this in my case I had to obtain a new copy of the object from the API after regenerating the model (e.g. myElement = myDocument.GetElement(myElementId);). I don't know if this will help in your situation but I hope it does.

0 Likes
Message 8 of 11

stefanome
Collaborator
Collaborator

Thanks for the advice. I just tried and in this stale case the cached info sticks around even after getting a new element. Adding these two lines before closing the transaction to my code, still return the wrong value:

group1 = doc.GetElement(group1.Id) as Group;
Debug.Print(groupType.Groups.Size.ToString());

groupType=doc.GetElement(group1.GroupType.Id)as GroupType;
Debug.Print(groupType.Groups.Size.ToString());

 

0 Likes
Message 9 of 11

mhannonQ65N2
Collaborator
Collaborator

Did you regenerate the model before getting the new element?

0 Likes
Message 10 of 11

stefanome
Collaborator
Collaborator
Yes, as suggested by Jeremy, but didn't help.
0 Likes
Message 11 of 11

jeremy_tammik
Alumni
Alumni