RevitApi 2022 update change WallCrossSection to WallCrossSectionDefinition

[ricaun]

Hello!

I was messing with GroupTypeId and found something interesting and a little worried.

On my computer, I have the Revit 2022 first release.

• Product Version: 20210224_1515(x64)
• RevitApi.dll Version: 22.0.2.392

On my plugin/application I'm using the NuGet package Revit_All_Main_Versions_API_x64 and I usually use the last version:

• Product Version: 20210921_1515(x64)
• RevitApi.dll Version: 22.1.1.516

And I found on the GroupTypeId the propriety WallCrossSection change to WallCrossSectionDefinition on the Revit 2022 update.

If I use this GroupTypeId.WallCrossSection gonna show an exception on the new version and if I use GroupTypeId.WallCrossSectionDefinition on the first Revit 2022 release gonna break too.

I probably never gonna use this ForgeTypeId, but which other thing could change on this update.

Should I be worried about my application break each time a new Hotfix was released?

[jeremy_tammik]

Yup, sounds bad. I asked the devteam for you.

[jeremy_tammik · Accepted solution]

Thank you again for pointing this out. 

It launched a significant discussion in the development team.

First of all, it did indeed happen as you noted.

Secondly, it should not have happened.

So, they are now discussing both how to handle this issue and how to prevent anything similar for occurring in the future.

The simple workaround for the moment is to use the integer value of the enum to cover both 2022.0 and 2022.1.

They discussed reverting back again in future updates, but that would cause even more disruption.

They discussed defining both enumerations with the same underlying integer values.

So, for the moment, just using the underlying integers is the safest way to go, I guess.

I'll keep you posted as the discussion evolves further.

[ricaun · Accepted solution]

I know this WallCrossSection is a new group parameter in Revit 2022, and I supposed is better to continue using BuiltInParameterGroup in Revit 2022.

A little problem is the BuiltInParameterGroup change name too, probably gonna throw some error.

The good news is the same enum value like @jeremy_tammik comment, I did not test but this code should work in both versions 2022.0 and 2022.1

// BuiltInParameterGroup.PG_WALL_CROSS_SECTION_DEFINITION; // -5000228,
// BuiltInParameterGroup.PG_WALL_CROSS_SECTION; // -5000228,
var PG_WALL_CROSS_SECTION = (BuiltInParameterGroup)(-5000228);

I supposed BuiltInParameterGroup and BuiltInParameter gonna become Obsolete and deprecated in Revit 2023.

That's why I was messing with each enum to check the ForgeTypeId equivalent.

[RPTHOMAS108]

---

@ricaun wrote:

I supposed BuiltInParameterGroup and BuiltInParameter gonna become Obsolete and deprecated in Revit 2023.

That's why I was messing with each enum to check the ForgeTypeId equivalent.

---

Not sure about that timeline:

https://help.autodesk.com/view/RVT/2022/ENU/?guid=RevitReleaseNotes_2022updates_2022_1_html

2022.1 Update > Issues Resolved > Parameters
"Removed the deprecation flag for BuiltInParameter/ForgeTypeId API mapping functions."

I can understand the units and the specs but what meaning does a BuiltInParameterGroup or BuiltInParameter have outside of Revit? My guess is the enums are a bit of a mess and they want to move away from them and give more thought to their standardisation but it's a task likely spanning more than one year perhaps.

The thing about Revit BIPs is that some exist to provide some form of object information beyond the usual storage types and some exist to allow Revit to understand the meaning of some input in order to provide functionality for that e.g. door width x door height = area. Then they get stuck in this loop thinking: 'well other items have widths so should we use the same internal parameter or differentiate them?'

They made a good step forward with the structural section parameters to facilitate the development of connections (everyone talking in the same dimension language). Before these all the content authors had different parameter versions of beam depth etc. So we couldn't then know what those parameters were for i.e. as an API developer there was no way of knowing the beam section depth from the parameters (we had to analyse geometry). If you worked with a single content author then you obviously were familiar with their parameters but writing something that could quickly extract parameter information for beam depth from multiple content authors consistently was not possible.

They now need to go beyond structural sections and have BIPs that define the properties of building elements not just think about what BIPs are required for Revit internally to work. What would really be useful is a dictionary of standardised parameters e.g. for each type of building element what aspects describe it and then what of those aspects are common with other types of element. The whole BIM thing breaks down if everyone is always defining their own parameters for things. Since you then need translations with people sitting down deciding how parameter information from organisation A should be fed into the parameters of organisation B for organisation B to understand their meaning.