Hi everyone, I just would like to understand something about ToDSType:
I would like to create a graph that takes the views I selected and duplicates them as dependents. So what I would like to do first is get a list of the selected Elements (first node and I am already stuck ):
clr.AddReference(“RevitServices”)
import RevitServices
from RevitServices.Persistence import DocumentManager
doc = DocumentManager.Instance.CurrentDBDocument
uidoc = DocumentManager.Instance.CurrentUIApplication.ActiveUIDocument
output =
selid = uidoc.Selection.GetElementIds()
for id in selid:
output.append(doc.GetElement(id))
OUT = output
It seems like I get an acceptable outcome, but:
I found another graph on the Internet that does the same but adds a .ToDSType(True) after doc.GetElement(id). Can someone explain to me why? Cheers!
It serves two essential purposes in the Dynamo context:
- It wraps the element into Dynamo’s equivalent Revit wrapper class so if you output these entities they are usable with all other Dynamo nodes.
- It performs element binding which basically synchronises elements between Revit and Dynamo and provides Dynamo with the instructions on how to marshal the elements while its running and when you re-open your graph. @jacob.small went into the details here: Element Binding in Revit if you want to know more.
2 Likes
Most of the time your elements will be wrapped automatically, so .ToDSType() isn’t always necessary. If your Python output looks like a Dynamo object (green element ID) then you’re fine. If it’s a Revit object (Autodesk.Revit…) then it wasn’t converted.
1 Like
That is true, but IMO a bad feature of Dynamo as its inconsistent (FYI @Michael_Kirschner2). As element binding is only achieved via ToDSType() there is a risk of unexpected results when you return the elements, so I would recommend always calling it when you know you need to wrap and not let Dynamo do it for you.
2 Likes
Didn’t realize this. Good to know.
1 Like