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.

(https://github.com/DynamoDS/Dynamo/issues/8058)
(https://forum.dynamobim.com/t/how-c-iterates-through-dynamos-geometry/37284/3)

Any ideas?
Thanks!

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…?

Thanks

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

Thanks

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: