How to check routing preferences of pipe type for a fitting existence in "Union" category?

gnab
Enthusiast
Enthusiast

How to check routing preferences of pipe type for a fitting existence in "Union" category?

gnab
Enthusiast
Enthusiast

Hello. I'm trying to check pipe type routing preferences of each selected pipe elements for an existence of default union fitting. I want to catch the Revit exception but it doesn't work.. I always get into this part of the code even if routing preferences have default union fitting. What is the problem?

 

gnab_0-1661345591072.png

 

0 Likes
Reply
Accepted solutions (2)
328 Views
4 Replies
Replies (4)

jeremy_tammik
Autodesk
Autodesk

What does the end user interface report when you look at your routing preferences there? The Revit API represents the same functionality as the UI.

    

Jeremy Tammik Developer Advocacy and Support + The Building Coder + Autodesk Developer Network + ADN Open
0 Likes

mhannonQ65N2
Advocate
Advocate
Accepted solution

This is interesting; in Revit 2020 I looked at the pipe types with Revit Lookup in some of the sample models and they had values for Union and most other related properties. The routing preferences UI also showed values for those fitting types. Next, I loaded another model, which didn't use pipes and thus had no pipe types loaded, and assigned union values in the routing preferences UI. But when I looked at the pipe type in Revit Lookup, it showed that those properties still had a value of null. The built-in parameter RBS_CURVETYPE_DEFAULT_UNION_PARAM also had a value of null, although its HasValue was true.

 

I went back to a sample model and duplicated an existing pipe type, Revit Lookup showed that its union property still had a value. I then went into routing preferences for the duplicated type and set all the entries to none. When I looked at it again in Revit Lookup it still showed its union and other fitting properties as having values, as did its built-in parameters. I went back to the original pipe type and changed the union entry from one fitting type to another but Revit Lookup showed that the union property and its corresponding built-in parameter still displayed the previous value. I also looked at the Preferred Junction Type; when changing it in the routing preferences UI, the PreferredJunctionType property on the PipeType remained the same, but the PreferredJunctionType property of the PipeType's RoutingPreferenceManager changed. 

 

Based on this, I conclude that the Union, Elbow, Cross, etc. properties correspond only to the built-in parameters, RBS_CURVETYPE_DEFAULT_UNION_PARAM, RBS_CURVETYPE_DEFAULT_ELBOW_PARAM, RBS_CURVETYPE_DEFAULT_CROSS_PARAM, etc. and not to anything in the routing preferences UI. And that changes to anything in the routing preferences UI are not applied to the built-in parameters and thus are not reflected in the properties. I presume that if you were to change the value of the built-in parameter it would change the value the property returns; but I don't see a way to change them through the UI so it probably can only be changed via the API. I suspect that in an earlier version of Revit these parameters corresponded to something the user could modify and these parameters retained their values when updating the model.

 

The Union property and other fitting properties of pipe types (I haven't tested other categories) should not be used as they do not correspond to anything that the user can change via the UI. If you need the union type, you should get it via the PipeType's RoutingPreferenceManager.

jeremy_tammik
Autodesk
Autodesk

That sounds confusing and problematic and unintended. Could you possibly provide a minimal reproducible case to describe in exact detail and prove irrefutably to the development team that we have a problem here?

  

https://thebuildingcoder.typepad.com/blog/about-the-author.html#1b

  

I think this should be reported for them to have a look and remove the obsolete properties if they indeed have no purpose anymore. Thank you!

   

Jeremy Tammik Developer Advocacy and Support + The Building Coder + Autodesk Developer Network + ADN Open

gnab
Enthusiast
Enthusiast
Accepted solution

I could catch this exception with try-catch.