Issue with OOTB "Categories" Node

Revit
1

Hi All,

The majority of my scripts use the OOTB Categories node however I’ve noticed an issue with the behaviour of this node. I save my scripts with the correct Category selected from the dropdown list within the Categories node, however when I re-open the script at a later date, the default category selected in the Categories node has automatically changed, and now displays a random category by default - causing my scripts to fail.

Example:

1
11920×1161 127 KB

In the example above, I’d saved the 2 Categories node inputs as Reference Plans and Scope Boxes, however they load up as Roofs - Substrate [2] and Ramps - DOWN text.

I’ve figured a workaround to “lock” the category by using the method below:

2
21251×585 19.5 KB

Whilst this works, it will take a fair amount of time to go through all my scripts and fix. I was wondering if anybody knew the cause of this or any alternative way to “lock” the input of a node with a dropdown list, or if anyone uses any other workarounds to avoid this issue.

On a side note, we recently upgraded from revit 2018.3 to 2020 and I was wondering if this could have cause this behaviour.

Any advice/comments would be greatly appreciated!

Thanks.

2

Changes in Revit version will cause this behavior, but starting in Revit 2020 with Dynamo 2.1 and up this should stop occurring.

As a means of ‘version protecting’ so the graphs run in 2020 and 2018 you can use the Category.ByName node which takes a static string to value as the input. This is also recommended for things like FamilyType and other drop downs where values may not be consistent between files or versions.

4 Likes
3

Thanks @jacob.small,

Good to know that this will no longer be an issue going forward. Can you confirm that similar nodes such as FamilyType which utilise drop downs will also be ‘version protected’ moving forward?

I will review all my scripts and reassign the correct Category inputs and re-save and hopefully this will ensure that scripts run as desired moving forward.

Thanks.

4

Unfortunately I don’t know. Family type is a much larger beast as that family may not even exist in the 2nd file, and how it reacts in that situation is worth exploring.

5

All good. Luckily a FamilyType.ByName node exists so I may just fool-proof any affected scripts and use this node instead. Thanks again Jacob.

1 Like