Modifying Groups

[Anonymous]

I've been working on a plugin with a feature to modify an element in a group based on the guide from the Building Coder (http://thebuildingcoder.typepad.com/blog/2010/08/editing-elements-inside-groups.html).  It gets some data from the group, explodes the group, makes the modifications to one of the group elements (no movement, just updating some parameters) then finds the other instances and replaces them.  The trouble is that the replaced groups don't end up in the same spot as they were before & they lose their mirroring.  See attached pictures. Is there any way to store the location differently or save the transformations applied to a group so it doesn'y do this?  Using Revit 2013.  Any help would be appreciated! Code:

        public void updateUnitProperties(Group unit)
        {
            Document doc = unit.Document;
            ICollection<ElementId> grpElements = unit.UngroupMembers();
            GroupSet unitInstances = getOtherInstancesOfUnit(doc, unit);
            GroupType oldGroupType = unit.GroupType;
            String oldGroupName = unit.GroupType.Name;
            Group newUnit = doc.Create.NewGroup(grpElements);
            GroupType newGroupType = newUnit.GroupType;
            if (unitInstances.Size > 0)
            {
                foreach (Group unitInstance in unitInstances)
                {

                    LocationPoint locPt = unitInstance.Location as LocationPoint;
                    Group newGroupInstance = doc.Create.PlaceGroup(locPt.Point, newGroupType);
                    doc.Delete(unitInstance);
                }
                doc.Delete(oldGroupType);
                newGroupType.Name = oldGroupName;
            }
        }

[Anonymous]

After wrestling with this a bit longer, I've found that the ungrouped and regrouped group was changing it's location point during that process, I got this translation and applied it to the replaced group.  This seems to put the group in the right spot, but I can't yet figure a way to check if a group was mirrored.

[Anonymous · Accepted solution]

So in continuation of this monologue... I eventually realised that even though groups don't have a 'Mirrored' property in the API, elements within the group do, so by pulling an element from the group and calling something like:

FamilyInstance mirrorCheckElem = Elem as FamilyInstance;
bool isMirrored = mirrorCheckElem;

I can get a boolean and use it to decide if the replacement group should be mirrored or not. Hope this saves someone else the hours I spent trying random boundingBox geomtry and unit vector stuff to try and figure it out. <:-)

[Anonymous]

I found this work:

1. ungroup the members and collect into a list
2. modify the members as required
3. create a new group with the members
4. assign the new group grouptype to the original groups

No need to mess around with where the groups are located at all. I'm using Revit2016 but I can't see any API changes in Revit 2014 through 2016 so it should be accessible in Revit 2013 as well.

[Anonymous]

Hi pkhlineworks

like you explained when ungroup and regroup, all the element id's and unique id's are refreshed with new values. my assumption is that these id's are for life of that element inside project.

[arnostlobel]

Yes, that is a correct assumption. Unique Ids of elements never change, and Element Ids may change during synchronizing with a central file (when two elements of the same Id get created in two locals and one of them must change it's Id upon merge).

The fact that some elements seems to change their Ids during group manipulation is an indication that the elements that exist after the group manipulations aren't the same elements which where there before the manipulation. For example, if - during a group modification - one element is deleted and later another element (albeit geometrically the same or close to same) created, it is not the same element - elements never assume Ids of other elements even in situations when a latter element replaces its previous version.

This is not unique to group operations. There are other processes in Revit that replace elements along the way, for example the Mirror command. Even though the geometry looks the same after mirroring (except for the mirroring effect, of course), all the mirrored elements are new with their new Ids.

Thank you

[Anonymous]

Hi Arnošt Löbel

Thanks for your reply.

my requirement is i need unique identifier on an element like door which should not changes unless user deletes and recreates same door again. Here is the reason we export elements from Revit and modify certain attributes values and bring back those elements to revit to apply those changes. so unless we have unique identifier, we cannot apply changes in Revit.

Any thoughts?

Thanks

Giridhar

[arnostlobel]

Hi Giridharprakash:

I have just (literally) gotten finishing talking to a colleague of mine who knows more about groups than I do. We've tried a couple of experiments and it appears that in a regular workflow - consisting of just ungrouping and regrouping - elements do not get replaces, which mean they will retain their Ids. We experienced the same even when we modified the ungrouped elements ever so slightly. So, our concussion is that in your case it is either a) the modification of the elements is of such nature that the group must recreated them, or b) that the modification alone of the elements make them to get recreated even before the group is re-grouped. Wonder if you could run an experiment on your side and report me the result here:


1. Take the group cluster you have and ungroup it (via the UI commands)

2. Note the element Ids

3. Make the modifications you do (via the UI)

4. Note the element Ids - are they different now?

5. Re-group the group

6. Note the element Ids - are they different now?

Thanks

Arnošt

[Anonymous]

please take a look a this video

i have tried this flow where you can see element id are changing.

https://onedrive.live.com/redir?resid=7CA9F8979B6AB3CE!15690&authkey=!AOaVkBg6oq2tX2k&ithint=video%2...

[arnostlobel]

Giridharprakash:

The workflow you presented in the video is different from what you explained previously, or at least it is different from what I understood. As is, the video with everything that is happening in there makes perfect sense to me; I do not see anything that could be classified as a bug or inconsistency. There you create several different (that's key!) groups that all happen to have two doors in them, except the doors in different groups are of different types. Then you change one of the group to become a different group and you - naturally, I'd say - observer that the elements in there changed. I do not see anything surprising there. Since the groups are different, they have different elements in them. If you change a cluster of elements from being a Group A to become a Group B, it is perfectly normal that the elements in the cluster will be different, since they have be the elements the Group B uses.

Arnošt

[Anonymous]

hi, You have the pseudocode to achieve this? or even the code or a link. I must do this not care about Ids, they can change like wind.

[Anonymous]

Sorry no I don't.