Parameter.IsReadOnly reporting incorrectly

I have browsed and browsed and can’t seem to find a solution to this problem so I am hoping I can find some help.

I have created a graph which finds all objects associated with a level and changes them all to a new level (whilst taking into consideration their offset values and calculating new ones if the type of object is one that moves when a new level is selected). The entire graph is functioning properly except for one aspect. I get a warning from the Element.SetParameterByName node stating that some parameters are read only. This is completely true and I am fine with some of the objects not being changed but I wanted to filter these out before the Element.SetParameterByName node so that my graph runs without warnings.

After doing a bit of research I found that if I used the following nodes I would be able to test for this and then filter the results accordingly:


This node shows the actual read only parameters correctly:

Unfortunately, this always returns true for every parameter it checks regardless of whether it is read only or not (see the above example). I feel like I have made some obvious mistake but I can not figure it out. Anyone have an idea of how I messed this up? :slight_smile:

Thanks in advance!

Can you share the whole graph I can try something

LevelChangeTestToForum.dyn (101.4 KB)

Here is a slightly trimmed version of it.

Try like this

@_Vijay So this sort of works but it brings up a whole new question: why would an element have two identical parameters and why would one be read only and one be not read only? I assume this is why the Parameter.IsReadOnly is returning true to everything because it is seeing two parameters for Level and at least one of them is true. See image below.


Hi @rdeardorff

Can you share the .rvt file?
I want to see those element categories of the List as per your ScreenShots

@Mepdot I can but I was able to reproduce the problem by starting with the default out of box template and loading the basic out of box toilet (I did this to make sure the extra Level parameter was not something within my template). So you should be able to reproduce this pretty easily.

You can create as many parameters as you’d like and in a variety of ways - and as such it’s easy to have multiple of the same parameter. I’ve seen models with 300+ ‘color’ parameters.

In this case the lower element id for the ‘level’ parameter is for the placement location and is read only as the value is automatically generated by the system based on the element’s placement. This is often not the value you’d want to see when coordinating locations as it can report that ‘top of plate’ level, or other values which don’t make sense from a communication standpoint. That leads to a read/write ‘level’ parameter added to enable the data being returned correctly, and should be the later element ID.

@JacobSmall I am assuming there is no way (outside of some Python coding) to separate one Level from the other is there?

There are always ways - check into what you can do with the parameter list after element parameters as one thought.