ZT nodes & [NodeCategory()]

Developers
,
19

Looking briefly into the behavior in 1.3 vs 2.0 I’ve noticed a couple things. It appears that these attributes work as expected in 1.3 as long as there is a public constructor for the class. Take a look at these examples…

NodeCategoryAttributeExamples
NodeCategoryAttributeExamples.jpg2313×1192 232 KB

  • Example 1 shows the default behavior in 1.3 with 2 (method/Action) nodes. By default an empty constructor is added even though it is absent from our implementation (no NodeCategory attributes applied)

  • Example 2 shows an empty constructor added to the implementation that was made private and the [NodeCategory("Query")] attribute is used on the AddSample node. This appears to cause one of our nodes (SubSample) to be tagged as Create node category even though it should be Action. This leads me to believe the library is expecting at least 1 Create node to be present. A work around would be to add a public constructor and hide it from the library using the [IsVisibleInDynamoLibrary(false)] attribute. Unfortunately it appears this attribute does not work on constructors from what I am seeing (but does work on methods or properties)

  • Example 3 adds a public constructor and applies the [NodeCategory("Query")] attribute on the AddSample node which appears to work as expected (but requires the a public constructor which now shows in the library)

  • Example 4 shows Dynamo 2.0+ where the default behavior is the same as 1.3 (no NodeCategory attributes applied)

  • Example 5 shows Dynamo 2.0+ with a private constructor which is automatically hidden from the library and achieves the desired behavior

TLDR: More investigation is required as to why constructors cannot be private or marked invisible without causing other nodes to be re-categorized unexpectedly in Dynamo 1.3.X. However, the desired behavior is achievable without workarounds using the latest Dynamo 2.X.

Hope this helps and please feel free to correct any oversight in the examples above.

3 Likes