Selection ID + Wrapping

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 :woozy_face:):


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:

  1. 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.
  2. 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. @JacobSmall 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