Zero Touch C# VS2019 custom node - incorrect input types

I’m writing a custom Zero Touch node that has the following method:

public static List<string> idFilter(List<string> uniqueids, List<Point> pointsReference, List<Point> mainPoints, bool[,] booleanSet, List<Polygon> polygons) { ... }

I’m getting a warning in the dynamo graph:

Warning: At least one element in the source array could not be cast down to the destination array type.

I’m using Lists, but I also tried ILists and that didn’t work. I think perhaps I should use IEnumerable but if I cast that toList() or toArray(), won’t that change the order of the indexes?

It’s crucial for me to keep the indexing unchanged.

I’ve looked online and found these similar topics, but not sure I completely understand them from the point of view of the error I’m encountering.


Any ideas?

What is the “,” used for inside the array brackets for the booleanSet?

indeed, I’m not sure any types in DS natively map to a 2d array like this - try bool

1 Like

Thanks @SeanP @Michael_Kirschner2 for your reply.

I originally had some errors with syntax so I opted for an array [ , ]
Changing it back to as you suggest doesn’t show any syntax errors, initially.

When I run the actual dynamo graph, from inside Revit, I get an "Index out of Range" exception.

But I can’t find a way to debug to understand exactly what’s going on… Revit throws and exception if you try to debug using F9 breakpoints in the Visual Studio environment.

Do you know how this process should work? I’ve tried to find a solution online but I think so far it’s only relevant to Dynamo Studio, and not Dynamo run inside Revit itself…

Any ideas…?


I am not sure we really have enough to go on at this point to help. without seeing the rest / full code example and how it is being fed in Dynamo, there are too many unknowns for us to really help. I would suggest sharing more information, or start with each input to the method and debug them one at a time to make sure they are coming in. Then just test often.

You cant use arrays as input types for public methods (i.e. ones which get exposed as nodes in Dynamo) since Dynamo lists (which is what a user will create before plugging it into your node/method) have no equivalent type and thats why you’re getting the cast exception. Change you bool input parameter to List<List<bool>> booleanSet and it will work.

Better still - declare your own types to handle your object model better (hence more nodes) and reduce your input parameters as that method signature is ugly.

1 Like

@Thomas_Mahon Thanks.
Can you elaborate a bit with a simple example in terms of how to declare my own types that translates to more nodes? I’m a bit unclear what you mean.
Do you mean to split inputs into separate nodes and then use a separate class definition to work with them further down the workflow?

@yafim.simanovsky sure, declare your own type which stores the data you are passing into your method.

I don’t know what you are trying to do, but looking at your method signature I am guessing that you want to iterate over each uniqueId, point, boolean list and polygon do something with this data. If that is the case then you already have the blueprint for your own type, e.g. each instance will contain a property which stores this data. Now, when it you call your idFilter() method (ps methods in C# follow pascale naming conventions so its IdFilter()), you pass in a list of your types. That would be much cleaner and represent your object model, avoid the need to pass around clunky ambiguous lists throughout your application and lend itself to SOLID software development practices. This other type, if you make it public, will be exposed in Dynamo as nodes after zt import, hence why this approach would naturally result in more nodes.

1 Like


The main issue was the List type for the booleanSet, which works as List<List<bool>>.
I did further testing also and split various functions and input/outputs to separate nodes to see where the problem was.

Thank you for your answers :slight_smile:

Hi @Thomas_Mahon

I’m writing another node and ran into an issue where my inputs defintions are Lists:

public static string GetData(Document document, List<Room> inputRooms)

as mentioned in your solution.
In the node implementation above I get an error while inputting Room Elements from the Lunchbox Room Element Collector, or from simply gathering all the Room Types in the model:

Warning: Geometry.GetData expects argument type(s) (Document, Room[]), but was called with (Autodesk.Revit.DB.Document, Revit.Elements.Room[]).

What’s not making sense to me is I have another public method defined which also takes in a List<Room> and doesn’t produce any errors.

Can you advise on what might be the issue here?
Thank you

Hi @yafim.simanovsky

Assuming the Room type you’ve declared in your method input parameter is from the RevitAPI and assuming the return type from the Lunchnox node returns wrapped Revit Rooms, then that’s whats causing the exception.

Any inconsistency you’ve mentioned will also be a consequence of the above, i.e. you are returning say RevitAPI rooms from one of your nodes (therefore unwrapped) and passing them into your GetData() method will work as its the same type. Really, if you are creating a library of ZT nodes then you must wrap any RevitAPI elements before you return them from your node as RevitAPI types are not native types to Dynamo.

Try this:

  1. Reference Dynamo’s RevitNodes.dll
  2. Add a using directive with an alias to either a RevitNodes.Room or RevitNodes.Element (this depends on what the LunchBox nodes returns, but Element is the default option if you’re not sure). e.g: using DynamoRoom = Revit.Elements.Room;
  3. Update your list type in your method: GetData(Document document, List<DynamoRoom> inputRooms)

Recompile and retest and it that should resolve the issue.

1 Like

Hm… thanks.
The Room elements I input to my ZT are Dynamo Rooms, so I followed the initial test of simply Unwrapping them and sending them as input that has access to RevitAPI (yellow circle in image).
I still get the same error if I send these kinds of elements.

This seems strange to me, given what you said about the Dynamo-RevitAPI relationship.

Thank you

Your advice works, thanks!
I’m just wondering about the above behaviour in Dynamo regarding Unwrapping / Wrapping.