Create Project Parameter(not shared parameter)

[Anonymous]

i did search how to create a project parameter.

i found how to create a shared parameter.

but i can't find how to create a project parameter.

help me

[RPTHOMAS108]

@pnunezcalzado  I was able to add shared project parameter to a key schedule via UI in 2022. So not sure if that limitation noted about shared project parameters is still valid.

[pnunezcalzado]

I'm aware that this is possible now! with 2022 Revit version. In another thread there is debate about it. Thanks for your comment @RPTHOMAS108 

[RPTHOMAS108]

Yes I was wondering if there was now any outstanding reason as to if a non-shared project parameter needed to be created via the API. I can't think of any off hand.

[pnunezcalzado]

My opinion is that if the non-shared parameters still exist, it should be possible to automate its creation with the API. If they are not useful, they should be removed!

To have something as important as the basic brick of data in Revit (a parameter), without the possibility to automate its creation, is weird.

[RPTHOMAS108]

In terms of API release each year they have to:

1) Keep up with the new UI features added each year
2) Close the gaps between UI and API functionality i.e. no way at all of doing something in API that can be done in UI.

3) Fix / improve things i.e. things not working as stated or falling short of exact UI functionality.

I think they do a good job at (1), most things you see in the 'what's new' relate to new UI features.

When we ask for things we should consider what we can live without already since there are plenty of cases of API not matching up with UI functionality (2). Pragmatically they are only going to add a small number from (2) each year after looking at items in (1) & (3).

I see non-shared project parameters as bottom of that list (2) unless these types of parameters can only be used for certain features? The only practical difference is one doesn't have a GUID and can be created without a shared parameter file.

Plus we always say 'use Element.LookupParameter as last resort'. So why allow the creation of more parameters where that is the only option? You end up relying on the ability of one or more humans to uniquely name something.

[ekaterina.kudelina.beam]

Considering the fact that it's not written in Autodesk Revit API documentation directly that method BindingMap.Insert can take as parameter only shared parameter definition ("A parameter definition which can be an existing definition or one from a shared parameters file.") and the fact that the definition can already exist in the project I tried another work around (which unfortunately failed as well). After creation a family parameter in some family I copied the parameter element into my target project, took definition of the copied parameter and tryed to bind it (also tried to delete the parameter after reading definition, since the definition object is still valid after parameterElement deletion). It doesn't work although if it doesn't return any error, just the insertion result is always false.

[martin.vollmer9PGT7]

Our company implemented a plugin, where the user can import wall systems. Customer parameters can not created as project parameters, that are not shared. That means, our parameters apear in the shared parameter file of the user. Some user companies have special shared parameter files and they do not want to have our parameters added into that file. So we would need to create project parameter, that are not added to the shared parameter file.

[martin.leonhartsberger]

Hi Martin,

the answer from ville.a.lehtisaari (#9) might help you out in this case.

The key here is to use a temporary shared parameter file

goto: Message #9 in this thread 

[juqing27]

Hi Martin, just to clarify, the parameter created in this way - no matter the temp shared parameter file is deleted or not - is still a SHARED parameter, not a project one, right?

[martin.leonhartsberger]

Hi!
Yes, you are right.
It's still a shared parameter.

[RPTHOMAS108]

Here is a thought experiment:

If the parameter was uniquely defined by the combination of its name and SpecTypeId alone then would you need a GUID at all for user defined ones?

You have two parameters:

Shoe Size, Integer

Shoe Size, Length

Obviously they can be distinguished from one another without the GUID. Also where they are used on families coming from different places they are obviously intended to represent the same feature of those families (for tagging).

There are obviously historical reasons for the GUID, I don't know the reasons (we always had ParmeterType). The common reason to use a GUID is to not have to consider in detail how to uniquely define something i.e. assign the GUID and forget about it. What everyone in BIM aims to do in the end is use a common set of parameters (set out the semantics of data interaction). This situation where one party uses ParameterA and another uses ParameterB to represent the same thing is unsustainable and is one of the largest problems in terms of the workflow. So many people are involved in the work of loading additional parameters to make their content conform with what is required externally.

Going back to the terms of this thread: creating shared project parameters is the only way you will be able to guarantee you can find those same parameters bound in the project later. You can use LookupParameter but if two parameters have the same name you'll perhaps get the wrong one. Nobody should want to be creating non-shared project parameters anymore as far as I understand it.

[icarus_au]

Hi all, I am working on the code to create a new project parameter for all structural elements and assign in Green Building Properties group. With the parameter, I can create a key schedule and provide various selection for all team member which can avoid incorrect input.

HOWEVER, I cannot find the correct way to create Project Parameter and put it in the Green Building Properties group. Currently I can create the Key Schedule by using Revit API. But I cannot create project parameter and cannot find a suitable Class to do so.

I have tried to create Shared Parameter by using API. But it doesn’t work as Key Schedule cannot read Shared Parameter as Scheduable Parameter（I know it works when using Revit 2022) Can anyone give me some insight? Thanks very much!

[nikolay.gerasimov3SGFN]

10 years later... Still the same. Autodesk just f*cks its users.

[ankofl]

Well, I think it's a fairly common situation when an organization has its own General parameters file (GPS), but at the same time they want to use an add-in using their own parameters. Of course, you can add to the general parameters file what is necessary for the program to work. But often the add-in is released by a third-party developer, the GPS file and entering into the GPS all the parameters required only for the program to work is not a very convenient idea. Especially if someone wants a different setup, or the same add-on, but a different version using different parameters. It would be great if this add-in had the ability to create and clean the file from the parameters necessary for its operation, without making it into GPS

[danalachemadda]

Hey! What about now? Can we create project parameters of type 'project parameter'? I only managed to create of type 'shared parameter'.

[miran2CLN7]

In response to the discussion in this thread about exclusively using shared parameters, I've been struggling with the limitation that shared parameters cannot be renamed once they are in use. I suspect this is going to create challenges for me down the road, especially if naming conventions evolve or need adjustments, or if there are project-specific parameter requirements.

This thread touches on that limitation: Solved: Rename Shared Parameter - Autodesk Community - Revit Products

I'm having difficulty weighing this downside against the benefits of using shared parameters. I’m not confident I can maintain a well enough structured naming convention from the outset, and I wonder if using project parameters would be better in case renaming becomes necessary later.

The inability to rename shared parameters seems like a strong argument for Revit to expand its API to allow the creation of non-shared project parameters programmatically. Would this offer a more flexible solution, enabling users to automate project-specific parameter creation without the permanence or cross-project complexity of shared parameters?