Warning: Multiple definitions for ‘Revit.Elements.Element’ are found as Revit.Elements.Element, Rhythm.Revit.Elements.Element
Multiple definitions for ‘Revit.Elements.Element’ are found as Revit.Elements.Element, Rhythm.Revit.Elements.Element
This happens since the latest update of the Rhythm package
the problem does not occur with the notation as I used in the lower code block
Why does it no longer work according to the notation used in the upper code block?
And what is the best way of text in code block? The upper of the lower code block? (if the Rhythm package wasn’t installed)
I don’t think the upper notation ever worked, although I could be mistaken - I’ve only ever seen the bottom notation. I do not have the latest version of Rhythm yet and the top notation does not work for me either. Bottom is the way you want to go anyway.
I always used the bottom notation.
But recently i discoverd the upper notation. And it works. On a other computer i have a other version off Rhythm and then it works.
probably if you did not install a package at all, the top notation will work as well
I am just curious Why?
I updated Rhythm to 2018.3.2 and I’m still only getting the “dereferencing a non-pointer” error. Not sure why you’re having a conflict with the package.
the only thing a learn from the warning is that rhythm have similar nodes :
Element.SetParameterValueByNameCaSeiNSeNSiTiVe
and
Element.SetParameterByNameTypeOrInstance
This is a namespace collision issue. Basically the dot notation doesn’t know which you want: Rhythm.Revit.Element.* or Revit.Element.* as you only told one of the two.
Try using a node to code function to find which method your curren setup wants (highlight an element.setparameterbyname node that’s wired in and right click the background). Please report back what you find.
I uninstalled the rhythm package in this last picture. as i told then the following notation works:
Revit.Element.SetParameterByName(element,“Breedte”,value_breedte);
Mostly in the code blocks i used the folowing notation:
element.SetParameterByName( string, value )
when i transform the Rhytm nodes to code blocks the script starts with Rhythm.Elements.Elements.etcetera
But Why have Dynamo problem with the first kind of notation(Revit.Elements.SetparameterByName(element,string,value)) when the Rhythm package is installed?
This is really classic namespace collision. Read about it here:
Dynamo for Revit has an Element class, as does Rhythm. So when you want to call that class you need to call the full module/library. By uninstalling Rhythm you remove the issue as there is no second Element class to confuse things. Note that packages which only contained the ‘classic’ custom nodes instead of zero touch ones don’t suffer this fate as they have no DLL and as such can’t be called directly via design script (to my knowledge).
Utilizing the direct operation as indicated in the node to code version elem.SetParameterByName(ParamName, ParamValue); is likely the best way to avoid this going forward, as Dynamo will only call the Dynamo for Revit modules this way. Note that the following variables can be changed as needed in that code: elem = the revit element you want to work with, ParamName = the name of the parameter you want to set, ParamValue = the value you want the parameter to be.
Previously I had all of my nodes bundled under a namespace called “RevitElements”. This was not in line with the way OOTB dynamo was, so I recently changed it. This does result in some of these kinds of things to keep in mind as @jacob.small pointed out. I can check it out some more as well, but I am not immediately sure if it is easily fixable on my end.
Is there any way to call a Category in a code block? Rhytm is conflicting with the OOTB namespace and I’m getting the Multiple definitions for ‘Category’ are found as Revit.Elements.Category, Rhythm.Revit.Elements.Category… error
I have this problem in 1.3.3 and 2.1.
I’ve reverted back to your package ver 2017.9.17 to get it working again. But I haven’t checked any intermediate versions.
Yeah, around that time I switched my Namespaces to better align with the built-in organization. Coincidentally, that cause this designscript issue. I believe @Konrad_K_Sobon had similar issues at one point and renamed his namespace from Element to Elements or something.
