Is there an easy way to convert family instance to element? I keep running into situations where nodes like All Elements of Family Type provide Revit.Elements.FamilyInstance but I need Revit.Elements.Element for the node Element.SetParameterByName or it’s package varients. I’m tired of constantly dealing with this.
Element.SetParameterValueByName will work just fine with a family instance. Most objects in Revit are elements as Element is a parent class, notice it is the second item listed in the object inheritance listing here: FamilyInstance Class
2 Likes
This is using Rhythm’s node but it was showing the same error. I have since fixed the parameter name input and it is working. How are you supposed to tell which input is causing the issue? If only one is the problem why should the warning list all the inputs? If all are to be displayed, maybe the offending input should be bold or red?
There, fixed the warning. This tells you what the problem is.
When you see these messages, find the stuff in parenthesis right after the ‘expects types’ bit, and look at what the data types it expects are.
In this case that would be (Revit.Elements.Element, String, var).
Then look for the stuff in parenthesis right after ‘but was called with’, and look at what those data types are.
In this case that would be (Revit.Elements.FamilyInstance, Autodesk.Revit.DB.Parameter, int).
Elements inherits just about anything Revit related, so we know the first input is good. And var is computer speak for ‘just about anything’, so we know to look at the data type for the second input.
Highlighting as you have done works in some cases, but not most (remember there are infinite data types which could come into any given input, and each of those may or may not have class inheritances to work with. This is one of those types of things where you just need to learn about data types and scaling of such.
Dynamo is leaving it up to users to know things already. If not, it will take them a while to learn what computer speak is. Why not have something that helps people make that connection right in the warning message. Hey all of these inputs look different to my dumb non-coder mind, but only one set is highlighted. Maybe those other things are fine.
The simple answer is that there are too many cases to ever cover, and ever growing. While the team would like to pull something together for every possible input error, it’d stifle all development progress if each node (and every custom node, such as the one you were using) had to code in a “the input here doesn’t work”.
Contextual highlighting would be nice where the data couldn’t be converted to a valid input type as you mocked up, but that is much easier to post process an image of than it is to dynamically produce in real time while scaling across multiple languages, integrations and a a variety of ecosystems without bringing Dynamo to a halt.
I’m am wondering though, have you seen the documentation browser? That was the teams effort to expose and highlight these warnings in a ‘plain language’ syntax. You can click on the ‘learn more’ link of the warning to access it. The dialog is intended to cover many of the most common warnings that Dynamo sees in simple terms while providing more depth, and also gives links to a forum search for the warning message directly. From there users can easily start up a new topic for more direct support from the community.
More here: Dynamo Core 2.6 Release - Dynamo BIM.
1 Like
I’ll look at it next time, thanks.
1 Like