Hi All,
I’m trying to set the [NodeCategory()] as per the following post
If I have just one method and I use [NodeCategory("Query")], the node is shows in the “Create” subcategory
If I add another method and I use [NodeCategory("Action")], now the first method is shown correctly but not the second 
My packages
Ideas?
can you post some sample code?
I have a solution with 2 projects.
1st project class:
using Dynamo.Graph.Nodes;
using System.Collections.Generic;
namespace Test
{
public static class RevitElem
{
[NodeCategory("Query")]
public static List<string> elementNo (string paramName, List<Revit.Elements.Element> element)
{
return Test_NV.RevitNV.elementNoNV(paramName, element);
}
[NodeCategory("Action")]
public static string concatenate (string name)
{
return "Hello " + name;
}
}
}
2nd project class:
using Autodesk.DesignScript.Runtime;
using System.Collections.Generic;
namespace Test_NV
{
[IsVisibleInDynamoLibrary(false)]
public class RevitNV
{
public static List<string> elementNoNV(string paramName, List<Revit.Elements.Element> data)
{
var paramValues = new List<string>();
foreach (var item in data)
{
Autodesk.Revit.DB.Element UnwrappedElement;
UnwrappedElement = item.InternalElement;
paramValues.Add(UnwrappedElement.LookupParameter(paramName).AsString());
}
return paramValues;
}
}
}are you testing these nodes in dynamo 1.3 or 2.0?
@salvatoredragotta @Michael_Kirschner2 the example posted above was done in 2.0+ with the new library, the behavior in 1.3 may have been a bit different and requires some investigation
@alfarok is it possible to use the the new library and use the nodes in dynamo 1.3.3?
@salvatoredragotta It may be possibly with some hacks as the library is really just a view extension but I wouldn’t recommend it. The library in Dynamo 2.0 was built specifically around other major 2.0 changes. Based on the date in the pull request linked above I would assume the NodeCategory attribute should work the same but based on your finding it’s possible it has regressed at some point around 1.3. We will have to take a closer look at the examples your provided.
If I remember correctly, those attributes are only read and applied for NodeModel classes / assemblies, while for ZT loaded assemblies only the xml documentation and the …_customization files are ever used.
@Dimitar_Venkov That’s a good point and seems to match what @Thomas_Mahon was saying in the other thread. It is possible in pre 2.0 builds these attributes only worked on NodeModel derived nodes but now both are supported in 2.0+
I’ve created a custom node using the code below (which implements the NodeModel interface)
I use the node category [NodeCategory("ExplicitNodes.Test.Query")]
But it’s still not shown correctly.
The Orchid Package for Dyanamo 1.3.3 seems to arrange the nodes correctly.
I wonder how it’s done 
Why not @erfajo and see if he’ll lend any suggestions?
Not following the thread (it’s outside my wheelhouse by a bit), but… have we checked the Orchid GitHub to see how that was done?
I don’t think he posts his raw code, just the compiled dll unless I have missed something looking there in the past.
That’s correct but there’s another repository with a few examples. I had a look but I can’t figure it out.
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…
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.
Thanks @erfajo but it doesn’t work with the correct spelling neither.
As @alfarok pointed out the library is expecting at least 1 Create node.
Hi, thanks for infos but how can I hide namespace?
