logged as case number 12933832. If anyone has a window family template that I can test for similar behaviour, that would be welcome as well.

Hi Ekko,

I think the issue is that length parameters are never allowed to vary within a group - I think this is expected behavior. If you test this you would get the same error.

1. create a wall
2. add an out of the box window
3. group both
4. make new group instances
5. select one of the windows and try to change the type.

Perhaps I'm not testing correctly?
Glynnis Patterson
4 Revit Plugins for Precise BIM Data Management | Ideate Software

Window & Window Template (zipped) enclosed (both 2016). At the moment I'm not sure if I've done any tinkering with the template file or not but I believe that one is still stock.

Hi Glynnis,
In my test, if the change in the type drives a change in the instance through a formula, this message pops up. I'll try your test with Chad's files (Thanks Chad!), but if indeed it does fail, I expect there to be a formula involved like in my example. I'll let you know what I find. Thanks for the contribution. I do hope Chad's window is OOTB? Not sure I installed those myself, must have them around somewhere.

The thing is, the warning seems the result of some unfortunate regeneration sequence rather then some fundamental logical problem. The whole point of the formula is to combine information from the nested Family Type and the host Family instance, both of which are supposed to always be consistent within the Model Group in the project.

What I now suspect is that the change in the nested Type DOES trigger the start of a regeneration of all the Nested instances of the modified Family Type, but the first of these regenerations also tries to alter the value of an Instance parameter value (by means of the formula). It is this first change that bumps into the Model Group auditing process that tries to maintain Group consistency. For a change in a Type parameter, the regeneration of the instances within Model Groups is allowed (pending Glynnis's experiment I'll stick with my results for now over the past decade), presumably because the Model Group auditing process holds untill all the instances of the Family Type are regenerated. If the start of the auditing process can be delayed until not just the changes of the Type parameter (and dependent family geometry), but also formula-dependent changes to instance parameters have been processed, the problem would be solved. This actually happens with non-nested families, just not with nested shared families.

Premature regeneration. I am so coining that one.

Definitely not an OOTB window

A few OOTB windows attached. :beer:

Hi Ekko,
Definitely will start using premature regeneration!

I made a video showing the most basic condition, using OOTB content. Revit just doesn't like changing the type, at least when it is hosted. The same operation would work fine for an un-hosted family that is changed within a group. Seems like a bug to me. Nothing to do with formulas or nesting, just premature regeneration for a hosted family.
https://www.screencast.com/t/zCFZkO0BBSz


Cheers,
Glynnis

You are quite correct that Revit does not allow you to change the Family Type itself if you are not in the group editor. This is normal behaviour IMO. I only realized where the mixup occurred when I actually performed the steps you described.
The misunderstanding is my fault, I named my Type parameter "type". When I said in step 8 'change type parameter 'type', I meant to alter the value of this Type parameter named 'type', not to attempt to change the Family Type.

I just tested with Chad's window (Thanks Chad!), and I can indeed not change the Family Type outside the Group Editor. I can change any Type parameter outside the Group Editor, even when I add a formula that combines the changed Type parameter value with an instance parameter value.
Only once I add a Shared Nested Family to the mix, with in that family a formula that drives an instance parameter, and in that formula I combine information from a Type parameter of the nested Family Type and, through association, from a parameter from the Host Family, things break.

Didn't get a chance to look at your latest upload file, but went back and demonstrated that changing the parameter named 'type' on your nested family is only permitted when it is changed from instance back to type. To me, this is expected behavior: https://www.screencast.com/t/kx6jQDY3Z

I was surprised to hear that you can change a type parameter that uses an instance length-based parameter. I believe if the formula has a number, but is not length-based, it would work, but then again, I'm often wrong!

Cheers,
Glynnis