Work sharing, Cascade Delete options

[grahamcook]

I’m making some modifications to an Add-In that until now has not supported work sharing.  The Add-In tracks and schedules equipment attached to various objects.  Each piece of equipment is represented by a hidden family that holds the characteristics of the equipment.  It has a HostId parameter (currently of type integer) that links the family back to its host (see attached image1.jpg).  This HostId parameter is there so that when the host is deleted, the Updater I have attached to the host will trigger and delete any equipment “linked” to that object.  So the basic process is:

User selects host object and presses Delete.

The Updater triggers and has a collection of all ElementIds that have just been deleted.

I get a list of families instances whose HostId parameter value matches the Id(s) in the collection.

I delete those family instances.

So far so good but now enter work sharing…

Syncing changes back to central cannot guarantee that ElementId's remain the same, I needed to stop using integers to store the ElementId (bad practice if your addin is to support work sharing).  So the way I see it I had three potential options:

1. Change the parameter that stores the ElementId of the host to a type of ElementId.  I have no idea how to create a parameter that stores ElementId’s either in the UI or through the API.  Is this even possible?  Is this reserved for system families?  Looking through a presentation by Scott Conover on work sharing considerations where he suggests we should use ElementId parameter values to store Id’s in a work sharing environment so I assume it’s possible?
2. Use UniqueId to store the host Id.  But then because there is no data.GetDeletedUniqueIds() method in the Updater there is no way to link the deleted item back to the families.  The only information i have in the Updater is the ElementId of the deleted item and can't lookup what its other properties are because they have already been removed.  If there was a data.GetDeletedUniqueIds() method then I could store UniqueId as the host parameter value and the problem would be solved.
3. Store the Host ElementId as an extensible storage entity using the ElementId storage type.  As I knew how to implement the extensible storage approach this is the one I went for.  Revit takes care of changes to the ElementId on syncing so I no longer have to worry about ElementId’s going out of kilter.  Everything is now hooked up and ready to go.

With option 3 implemented and with my equipment families “linked” to my host object (a floor), I delete the floor and debugged through the Updater code.  I get a collection of families that have my extensible storage entity attached and whose stored value matches the ElementId in the Updaters data.GetDeletedElementIds() collection.  This always returns 0 items because Revit has reset the stored ElementId value in the extensible storage entity to -1 as the corresponding element (floor) has just been deleted!  Expected behaviour I guess as Revit is keeping element Id’s in sync (even the deleted ones).  What might work is to get a collection of all families with the schema entity attached and whose value is set to -1.  I know these family instances no longer have a valid host because their stored host ElementId is -1 so it’s safe to assume they have been orphaned and delete them.  That will kind of work.

So I’ve been looking for a more Native way to link the families to their host object so that they automatically get deleted if their parent is deleted.  I tried setting the Host when creating the family instances thinking that if the Host is later removed, the items hosted will also be removed but that wasn’t the case.

Is there a better way of achieving a cascade delete setup in Revit that is work share friendly?

Graham Cook