I'm running into this same problem. It's probably not the thing everyone does on a day to day basis but I've got myself in a situation where I need to do this.
I have a family with nested families which are controlled by a "<family type>" type parameter. In the API, I've snooped to find the element id for all of them and I've hard-coded this into the tool. My concern is that if this family is loaded into another document then the Id it gets, may be different. (or may not, I've really just been working on getting the main functionality going).
I've searched all the elements and element types in the main document via filteredElementCollector and cannot find one named "Circular", however, if I ask the document to get the element associated with my hard coded Id, it gives me an element with the name "Circular".
So, same question as above (I think): Where is this element and why does the filtered element collector not find it?
Next question: is hard coding the id a "safe" thing to do? i.e., is it stable? It surely doesn't seem like it hence my quest to seek out the element Id on the fly.
(Did one FEC with WhereElementIsElementType and one with WhereElementIsNotElementType and querying either list does not find an element with a name of "Circular" but if I revitDoc.GetElement(circular element type id) I get an element with name == "Circular".
In case I've done something hair-brained in late night coding:
Element circleElem = revitDoc.GetElement(new ElementId(173049));
FilteredElementCollector circleCollector = new FilteredElementCollector(revitDoc);
circleCollector.WhereElementIsElementType(); //.WhereElementIsNotElementType();
IEnumerable<Element> circles = circleCollector.Where<Element>(s => s.Name == "Circular");
if(circles.Any<Element>())
{
MessageBox.Show(circles.First<Element>().Name + " ID: " + circles.First<Element>().Id.ToString());
}
It never hits my messagebox in either case (element type or not element type). circleElem has a name of "Circular"
Has anyone already invented this wheel?
Thanks,
-Ken