Parameter Set returns true but does not change the value

[m.de.vriesTH5VM]

I have code that has been working correctly for years that apparently stopped working correctly in Revit 2023

It is a basic method to set a parameter to a string value, but the same problem also occurs with the similar method for setting double values

public static void SetStringParameter(Parameter par, string waarde)
{
	if (par != null && !par.IsReadOnly) par.Set(waarde ?? string.Empty);
}

This function gets called with a valid Parameter and string value, and the parameter is not read-only. The par.Set() method is called, and when I check it in the immediate window it returns true. However, the parameter still has the original string value.

The parameter definition is

The parameter is not read-only, it has storage type string and is a normal Family Instance parameter (the family was upgraded from Revit 2022). The UserModifiable being false is odd as I can set the parameter value from the GUI (which if I understand correctly, this setting should prevent), but that is not the issue I hope.

I am trying to figure out why Revit either ignores the Set method, or quietly rolls back changes before exiting that method. And more importantly what I can change to make it work again as it should.

I am a bit at a loss here because this method has always worked correctly since at least 2015 and no code changes were made anywhere near this method, or the ones that call it. In case this unexpected behaviour has something with the family I attached the RFA file. I am trying to change the 'familynaam' parameter value among several others.

Thanks in advance for any help or suggestion

Mark de Vries

ICN Development

[RPTHOMAS108]

I'm not sure why you are using the null coalescing operator there? I don't believe there is any consequential difference in setting the parameter value to null or empty string "" (to clear the value). I suggest you try without it. I think the method is wise enough to equate null input to a desire to clear the value but now you have me wondering. I came across issues with dealing with null values in generics i.e. is the type known when it is null?

However I'm not sure what difference in behaviour any of that would cause between versions (apart from the target framework perhaps and how such language features changed). Since the set method is overloaded I would be declaring a string and feeding that in (if it null so be it).

Likewise for double once it has a value you can't remove the value to anything other than 0.

UserModifiable has a commonly misconceived meaning: the 'user' in question is the end UI user not the developer of an add-in. User modifiable is a flag you set in a shared parameter definition to restrict editing of that parameter to the end UI user (is still writeable to any add-in regardless of who created the parameter). UserModifiable is only applicable to shared parameters, the value is false by default for all other types or parameter (but that is meaningless i.e. the default for Boolean is false). Would have been easier if they had called it 'NotUserModifiable' or 'NonUserModifiable', so that where it is set to 'true' it has that meaning.