How to truly purge Project (Shared) Parameters

[Dale.Bartlett]

To a project:
Add a Shared Parameter
Remove same Parameter
Save/Purge/Close Project
Edit Shared Parameter file to change name of same Parameter
Add changed Shared Parameter into same project
It will retain the original name as when it was first added.

I know the GUID is the defining ID, also the implications of the Parameter having been used elsewhere, also that the Shared parameter file is not designed to be edited manually. However, in my case I simply want all references to the original definition removed from my project file. I have tried many code snippets, and searched for hours with no success. Anyone?

[Dale.Bartlett]

Follow up thought: Ideally a nominated Shared Parameter GUID should be deleted/purged. Dale

[jeremytammik]

Dear Dale,

Thank you for the query and suggestion. I am discussing this with the development team.

Happy New Year to you!

Cheers,

Jeremy

[jeremytammik]

Dear Dale,

Thank you for your report and patience.

I discussed the issue with the development team.

Happily, a perfectly feasible workaround is available:

It is possible to manually remove a shared parameter completely by deleting it by ID.  You can even do this in the UI using Manage > Select By ID to select the element and then pressing the Delete key.  This should be possible through the API as well.

The UI intentionally never completely deletes a shared parameter from project files, for two reasons:

1. It is difficult to know if a parameter is completely unused, for example it may be unused in the project, but used by some loaded family.

2. Issues can arise in workshared files when one user removes a parameter and another user simultaneously starts using the parameter.

In family files #2 is not relevant, and we found a solution to #1, so now when the user removes a shared parameter from a family it is completely removed from the file, assuming there is nothing else using the parameter (like a nested family).  In projects, #2 is still a concern.  For example, if one user removes the parameter while another user loads a family that uses the parameter, the result will be a family that is missing one of its parameters.  So it is not easy to completely solve the issue in a way that end users can safely use, but if you are careful, deleting a shared parameter by ID can work fine.

I hope this helps.

Best regards,

[Dale.Bartlett]

Hi Jeremy,

Thanks for the reply. I am using the following test code to capture an Element Id for a named parameter attached to Sheets:

<code/>

public static void GetSheetParams(Document doc, stringParameterName)

{

string SheetInfo = string.Empty;

 foreach (Element e in new FilteredElementCollector(doc).OfClass(typeof(ViewSheet)))

{

// get the parameter

Parameter p = e.get_Parameter(ParameterName);

 // get the string value of the parameter

string ParamInfo = p.AsString() + " Id= " + p.Element.Id.ToString() + "AsElementId= "+ p.AsElementId().ToString();

SheetInfo += ParamInfo + "\n";

}

TaskDialog.Show(ParameterName, SheetInfo);

}

</code>

p.Element.Id.ToString() returns a recognisable Id, however I am unable to use that in the manner you suggest. A parameter is not a selectable element as far as I can determine. p.AsElementId returns -1. Would you have a further example or comment? Thanks, Dale

[jeremytammik]

Dear Dale,

You can use the element id stored in the parameter p "in the manner I suggest" like this:

  ElementId id = p.AsElementId();

  doc.Delete( id );

Obviously wrapped in a transaction.

Sorry, much too fast.

p.AsElementId() is the Revit element pointed to by the parameter p.

You do not want to delete any element pointed to by p, you want to delete p itself!

Therefore, what you are after is simply p.Element.Id. As you say, it returns a recongisable id. So try

  doc.Delete( p.Element.Id );

However, until a couple of minutes ago I would have said that you need to delete the parameter definition, not the parameter instance, in which case it would more probably be

  doc.Delete( p.Definition.Id );

Good luck and have fun!

Let us know how it goes...

Cheers,

Jeremy

[Dale.Bartlett]

Many thanks Jeremy,

You make it look easy... I haven't tested yet but will let you know.

As "p.AsElementId() is the Revit element pointed to by the parameter p", and my case returns -1, can this be used as a flag to determine whether the Parameter has been referenced?

Dale

[jeremytammik]

Dear Dale,

Thank you!

In my experience, almost everything we can do in Revit is very easy indeed.

If it is hard, it either cannot be done or is heading in a wrong direction.

I think that goes for most other programming as well, and most things in life in general.

I would rephrase "determine whether the Parameter has been referenced" to "determine whether the Parameter is referencing a valid element".

Cheers,

Jeremy

[tkdes-info]

Hello Dale and Jeremy,

I'm newbie on Revit and programming on.

I'm a developper in LISP on Autocad.

I use an addin on Revit which create some shared parameters, when I want to sent the rvt file to my customers,

I must delete manually all this parameters. It's a little long.

I create a little c# project with my personnal tab (thank's to Victor Chekalin for his example).

And wanted to create a fonction in order to erase automatically the shared parameters.

I used this example for starting :

http://forums.autodesk.com/t5/revit-api/reporting-on-project-parameter-definitions-need-guids/td-p/4...

But I don't understand how to apply the delete method.

thank's for help.

Sebastien.

[leonHKFTG]

Hi, and sorry to reactivate this after so long. I do understand the issue with Shared parameters and the case for making it impossible to eliminate from a project. However, I think they are incredibly unforgiving. I am preparing an automated method to perform BOM's by introducing parameters from an excel file. Everything is going well, I just made one fundamental mistake, I chose "number" instead of "text" for 3 of those parameters when I included them in the shared parameters file. Now Dynamo is reading the excel file either as integers or strings, and when I have Dynamo read the excel file parameters to be set into the families, some go through and some don't. So now I can go back, change those parameters in the original shared parameter file and re-introduce them, but the original ones will remain forever in the file as a useless duplicate, and worst of all, I have done this in the template. Is there really no way to get rid of them? No workaround whatsoever? Thank you

[leonHKFTG]

Figured it out, I could eliminate the old shared parameters, nm

[jeremy_tammik]

Good for you! Congratulations! Would you like to share how, and what the problem was? Thank you!

[leonHKFTG]

I erased them from the Project Parameters list. Then went to the original shared parameters file, eliminated those parameters and re-created them with the right category for my convenience, and finally re-introduced them and assigned them as project parameters again. This has worked for this file in particular, I have another file where this procedure hasn't worked and a ghost parameter still persists. I'll investigate further. The issue may be related, in that case, to the shared parameter being present in some families. I've read that eliminating the parameter from them may fix the problem. Thanks

[jeremy_tammik]

Thank you very much for sharing your approach!

I'm sure this will prove very useful indeed to others struggling with this.

Yes, the shared parameter ghosting around in any other document whatsoever will certainly make it hard if not impossible to modify.

Sorry that the approach is so convoluted, and certainly not officially supported either. Historical reasons, of course.

[leonHKFTG]

I appreciate. Take into account that there are surely things that are escaping my understanding, that's why I came here, I can't really tell if there is something I'm doing wrong or not doing yet that I should, it may very likely turn out there is no such problem at all with shared parameters but just a lack of knowledge on my side. Pleasure to exchange thoughts here,

best regards

[Dale.Bartlett]

I must admit to letting this one slip through the cracks. However, I think you will find that the shared parameters cannot be removed from a project (Family - yes). You may have been able to change the category (I've not tested), but I think you will find that you will not be able to make data-type changes, name changes, or delete them entirely. I am happy to stand corrected, but I am yet to see any working code that does this.

[leonHKFTG]

Hi Dale

I believe we are on the same page, at this point I have a file where the shared parameters that needed to be corrected, are corrected, while on a different file, I have a ghost shared parameter that simply won't disappear. I must highlight one possibly relevant factor, which is, in the file where I could fix the problem (at least avoid any inconveniences) the shared parameters ended up having the same names as the original ones, on purpose. This all started when I realized Dynamo wasn't able to populate the shared parameters fields back into the targeted family types, since those fields were expecting numbers while the excel file was set to be read as strings, and therefor tried to send strings back into those fields in Revit. All I did was eliminating the original shared parameters in the txt file (through the Revit interface) and then re-creating them with the same exact name, but this time categorized as Text parameters, and finally re-introducing them into the Revit file as Project Parameters. I still think that they are being accounted for as different Shared Parameters from the originals, so I don't know why this has worked on this particular file while on a different one I have a greyed out ghost parameter even though it no longer exists in the Shared parameter file and it has been eliminated from the Project parameters list. I'll keep testing with that file, I'll come back here hopefully before EOD. I can't therefor consider this as resolved until I find a way to have those disappear.

Thanks

[RPTHOMAS108]

The below is conversation strictly related to parameters bound in the project.

Are people speaking of deleting SharedParameterElement/ParameterElement objects or using the methods from BindingMap such as Insert and ReInsert?

Since the former was introduced there are now two ways of doing the same thing but I'm unaware if the stated limitations relate to both or not i.e. what is BindingMap.ReInsert for if you can't replace one parameter with another or does this method also expect the same GUID or Name or Storage Type (i.e. perhaps it only allows changing name or GUID etc)?

I can see why these old parameters may persist i.e. where are the values stored? The binding map itself is a flat list of category associations for these types of parameters but the values exist on the element or perhaps are on other objects linked to the element? Ideally ReInsert would just delete all the old values if a parameter of different storage type was introduced to replace an existing one but that may involve issues such as workset availability (although easy for the API to throw an exception for such situations perhaps).

Would recommend a system where your internal parameter values can be mapped to newly bound ones to satisfy external needs rather than trying to replace your internal ones. Probably easier to transfer values over and delete your internal ones if they only relate to COBIE, IFC etc. and are not driving geometry. 

[leonHKFTG]

I keep your advise in mind, much appreciated.