Hi!
I have a task to create a number of Revit project files containing one wall type in each and to add specific parameters and values to it.
Then I have to make a “master” project file containing all of these wall elements, parameters and values in it.
I have created all of the parameters in single unit files with Dynamo
Then I copied individual wall elements from single project files to a new master project file and soon after I noticed that Revit duplicates, tripples and quadruplicates these parameters.
Then I made a test and created a new parameters in those single unit files with different Dynamo node and repeated the same copying task and parameters were not duplicated anymore.
When I checked parameter ID’s then in case where parameters got duplicated they remained with the same ID’s across all files. But in other case where Revit did not duplicate parameters their ID’s changed across project files.
My question is this: can someone please explain me what is going on, how parameters work or whatever useful to enlighten me
Shared parameters rely on a GUID. When they are created and added to a project - they area there forever. (unless you are clever.) If you add another shared parameter with the same name programmatically - the old one is still there, and you get the new one with a different GUID. A lot of the nodes and programs I see, generate a shared parameter “on the fly” - so you end up with a different shared parameter every time you make one of the same name. Very bad.
The only way to make sure you have a one of a kind persistent shared parameter, is to make sure it is in your shared parameter file. Or make sure your program always generates the same GUID (which is kinda against the whole idea of GUID.)
When I need a shared parameter:
- I save the setting for the current shared parameter file of the project.
- Write a custom shared parameter file out to a temporary file.
- Set the temporary as the current shared parameter file.
- Load the parameter definitions I want from the shared parameter file.
- Reset the shared parameter file to its old setting.
- Delete the temporary shared parameter file.
This ensures I’m in control of the names and GUID and no one else in the office is messing with these settings.
Well said.
I will note that hard coding a GUID is quite valid for many applications; in fact this is how extensible storage works; as long as each schema has it’s own unique hard coded GUID it works brilliantly. First time someone fails to make a new GUID for a new schema is where you start to get into trouble. I haven’t tested it yet, but I imagine shared parameters are also this way.