Key Schedule + Revit API

[sobon.konrad]

I have previously asked about using Revit API to create a Key Schedule and add bunch of new parameters to it. That questions is still out here somewhere so I am not going to repeat it here. Instead I just manually added bunch of parameters to Key Schedule and moved on to the next task. 

I was able to access Data Table and add more rows to the data. What I am trying to do now, is to fill the cells with data. Obviously, there is no clear method for that. Hence my question: How does one, using API, fill in the Key Schedule data? Any ideas/suggestions are welcome. 

Thank you,

Konrad

[jeremytammik]

Dear Konrad,

Snooping around in the Revit API help file RevitAPI.chm, I see the ViewSchedule.KeyScheduleParameterName property that provides the name of the parameter for choosing one of the keys in a key schedule.

Maybe you should snoop around a bit yourself as well.

Cheers,

Jeremy

[sobon.konrad]

Jeremy,

Yes, I saw that too. I guess I fail to understand how to use KeyScheduleParameterName to select a Key and then write some information to it. Care for an example? I am sorry, if my question is a bit on a noob side, but I am not an experienced Revit API programmer, and you are far too nice of a person (we met before :-)) to give such dismissing answer. Also, Revit API is not the easiest thing on earth so please give me some leeway if my questions are not exactly challanging. Trust me, they are challanging enough for me. 

Thank you,

Konrad

[jeremytammik]

Dear Konrad,

Thank you for your appreciation.

My answers are often evasive because I am evading the question.

I cannot answer this one myself without doing research.

Let's wait until next year.

If it is not solved by then, I will either take a closer look or pass it on to the development team.

Thank you for your understanding.

Cheers,

Jeremy

[PaulusPresent_BB · Accepted solution]

Dear Jeremy and Konrad,

Maybe I can be off help. I just had to deal with this problem as well and wanted to share my findings with you.

A keyschedule behaves in most ways just like a normal schedule. The most important similarity being that they show a collection of elements.

Confusion can arise when thinking about the elements in the keyschedule, because they do not physically exist in the revit model. I like to think of them as 'ghost elements', who's image (= set of parameter values) can be imprinted on real elements.

This being the case, the elements in the keyschedule can be simply retrieved by using a FilteredElementCollector with the KeyScheduleID as an argument. Parameters shown in the keyschedule can then be retrieved and set in the elements themselves. The newly set parametervalues will then ofcourse show up in the keyschedule.

Kind regards and my excuses if this post is too obvious.

I hope someone still has some use of this info.

Paulus

[JeffYao28]

This solution works pretty well!

[sobon.konrad]

Ah! I see. Now just to make it clear for everyone here's what reall happens: 

Each row in a Key Schedule is an Element that contains a set of Parameters. Parameters represent each column of the schedule. 

We can collect all "rows" (elements) just by doing this: 

elements = FilteredElementCollector(doc, viewSchedule.Id).ToElements()

Then we can query each element that is being returns for parameters: 

params = []
for i in elements:
   params.append(i.Parameters)

Once you have the parameters you can just write values to them and they will appear in a schedule. 

Cheers! 

[JeffYao28]

Thank you for making that clear!

Not all parameters are representing a field in the key schedule, though. But that can be easily filtered out by checking the parameter's definition name toward scheduleable fields.

Maybe the Revit API SDK team can include some of the code in the schedule samples, before a more intrincit method for reaching this goal being created.

[Anonymous]

Hi Konrad,

Would you mind sharing with me your code?

I’m new to the API but being able to stich codes that I’m finding here and there. However this one I’m failing so far. I’m able to filter my key schedule, able to get to the column I need. BUT NOT able to read the data of that column.

Any help you can provide is much appreciated.

Thanks

hisham

[ghaith.tishNS5ZX]

Which parameter is responsible of defining the herarchy of the scheduel in project browser ?.

Where the question marks in the the loaded picture are.

[ghaith.tishNS5ZX]

 

[ghaith.tishNS5ZX]

I have used the concept but there are no elements collected in the 

Category category = Category.GetCategory(doc, BuiltInCategory.OST_Rooms);

viewSchedule = ViewSchedule.CreateKeySchedule(doc, category.Id);

FilteredElementCollector elementCollector = new FilteredElementCollector(doc, viewSchedule.Id);
IList<Element> rows = elementCollector.ToElements();

[jeremy_tammik]

I asked the development team for you.

[jacob.small]

Not a Revit developer, but this is something I've taken a stab at in the past for a Dynamo project, so I'll weigh in.

First thing to know: the project browser is a view of the model itself, and can be organized in different ways per project. As always, you want to explore how things are in the UI before attempting to automate it, so here's some info on managing it manually: 
https://help.autodesk.com/view/RVT/2022/ENU/?guid=GUID-96F9CDB5-C46D-4597-943B-DF231E8EC688

From there we can look at managing it via the API. For that there is a handy class: 

https://www.revitapidocs.com/2024/4fd57c3f-6127-efd9-f79e-70ad3e5dc1cc.htm

So while we could manage the setup, we don't know how your browser is organized on a given project (and if your code is intended to scale across orgs/projects you can't assume there is a single setup). As such you likely want to have a look at this method to start: https://www.revitapidocs.com/2024/b32365b9-54d0-08b3-ee34-4a2cde7fa1d8.htm

Good luck. 🙂

[GallowayUS_com_RonAllen1]

Quick footnote- in case anyone attempting to use "Non-user-modifiable" parameters(NUMP)... They won't translate through keys into schedules.

IMO it's a bug or at the very least needs to be added as a feature! ( Case#20712754, Cross-support post to ADN case#20837279)

Using a Key should be a pointer to the parameters values in that key... unless its recreating a new instance of the parameter and copied the data to the NUMP, even then, this this is an API, not a user move- but key values come up blank(Ugh). Plenty of cases where we want to require extra steps or tools to load data that is otherwise protected in the NUMP.

All the places we would use key schedules where we would load data (VIA Dynamo, PyRevit, API, Ideate- whatever) for E.g. Code fixture calculations, Hardware sets, Occupancy loading, material representations, and maybe a hundred others I can't think of right now.

[RPTHOMAS108]

Perhaps or perhaps not.

Historically you couldn't use shared parameters in key schedules. So since the non-shared version doesn't support 'non user modifiable' it perhaps may be something that wasn't considered when the change was made allowing shared parameters in key schedules.

However isn't a key schedule just a schedule containing parameters without associated elements? So I'm kind of wondering what the purpose would be in creating one that a UI user couldn't modify the values of i.e. just a constant value assigned by developer? It is probably by design to deter people (developers) creating vast tables that are not backed by associated elements. Was that your motivation: creating tables of information not linked to elements? We've all had that 'why can't I shove an Excel worksheet in a view' moment but we know deep down there is a good reason not to.

Now that key schedules work with shared parameters I think they should just completely do away with non-shared project parameters and just assign Guids to such during the next upgrade (would anyone other than the ad hoc, bad planning types care?).  A non-shared project parameter is just a shared parameter nobody could be bothered to put in a shared parameter file. However this is just another subject altogether. These are the things I care more about i.e. why do the non-shared project parameters still exist? In a family fine, in a project no!

[GallowayUS_com_RonAllen1]

@RPTHOMAS108 With the advent of being able to use them it would help those of us getting into the API to understand the core underlying operations and logic how things are put together. 

Having Keys that I load in filled with data I don't want people to intentionally or unintentionally change- occupancy loading is a prime example - is critical, and all that data transferrable VIA a key to a room or space makes it easy to tabulate. Otherwise I am off to plan #2 which is code it in the API and create parameters to manage on events.

But there are so many things we could use these for but can't to one seemingly insignificant issue with NUMPs in key schedules. 

We as human beings always want more from our tools and content - it is what drives innovation, improvements and what updates(Like shared parameters in key schedules) are all about! 

If we can shape it to solve a lot of problems - it makes the software a little more accessible to everyone.

[RPTHOMAS108]

I think you have other avenues in terms of preventing changes to a given parameter i.e. Failures framework.

However when these restriction are made there is often the scenario where the restrictor doesn't fully allow for the workflow of the restricted.

Probably it is better to understand what people are doing wrong and the reasons for their actions via periodic model audits prior to each issue etc. The other strategy is probably to hide the key in extensible storage, link your external data from elsewhere into the model an then audit it prior to issue.

I understand the problem all too well. There are numerous cases where type parameters are changed locally without looking at the consequence for all instances. Also seen people messing up type parameter values in a beam family because they were editing the sizes in the tags as if they were editing an Autocad drawing (so suddenly one UB is calling itself another UB). Audit picks up these things when something isn't what is should be. Also Revit does other things between issues (dimension refs going missing) so audit of what you had at last issue vs what you are about to issue (checking changes are what you anticipated) is vital. One elevation level goes missing from one end of an upstand on plan and suddenly the upstand that should have a sloping top turns into an upstand of constant level  (that then needs a remedial detail to either build up or cut down). 

Revit is definitely dangerous in the wrong hands. Train the people, spot the mistakes before they have consequences, identify the retraining needs and potential for improving the training, repeat.

I'm trying to think of a good analogy, probably it is self driving cars i.e. should someone who has never learnt to drive be able to drive one? At this point in time no but in the future that is the ambition. So how much do you trust your system of restrictions at this point in time vs the user having to know right from wrong in terms of your Revit protocols? Perhaps I'm being too binary about it since there is always the potential for a lapse in concentration that an automated system could catch.

[GallowayUS_com_RonAllen1]

@RPTHOMAS108  in this case it's more than just protecting the data... To calculate fixtures on the fly we have 27 points of data to accommodate the different scenarios in the 2902 table of the IBC plus its extensions in section 4.

This data is way easier to edit in a spreadsheet, and it will be easier to accommodate calculation instances for NYC, Chicago, SoCal, etc. 

The data is already managed VIA excel in tables that has a tool for exporting to a Revit family Library- which then users can opt to select to bring in VIA Filters and loading using the library loading tool. If the data is wrong we fix it one place- reload and updated.

User picks one type for calculation, enters 2-4 pieces of data and it instantly calculates fractional fixture counts... Within Revit. Phase 2 is Occupancy loading to connect to the tables, and or API to calculate occupancy loading, select the appropriate instance for the fixtures and push those values to get totals.

Because the tables are in excel - It can also be repeated outside Revit if needed.

API eventually builds modules for even more detailed use in other ways around the same base, core data.

[RPTHOMAS108]

That is interesting but perhaps you would be better off taking the calculation inputs from Revit, using those in Excel then bringing the results back to Revit rather than the other way around (if I understand you correctly).

Regarding the issue you mentioned, you are getting the below I presume:

Probably needs investigating further as I don't see the reason for it. The parameters can be given values but as you say they don't link into the actual element set to the associated key.

Typically for other key schedule parameters I read elsewhere that it occurs as a result of a conflict in the parameters of the associated nested families but the above is a room. It is likely there is some form of criteria for this condition above arising that perhaps is being wrongly applied to the non user modifiable parameters.