I'm sure we've all been there, that one parameter we have to have in both the host and the nested family, but for some reason the value is being driven by the nested family and not the host. Oh well, tough luck. Re-design your family, or re-create the conditions in the host family (regardless of whether they're needed there) or just drop the whole nested family to begin with and make it all in the same family.
What? Did you say reporting parameter? Buah ha ha hahah ahahahahaaaa... Sorry. Those only work on geometric constraints, can't be used to determine the value of some parameter types, can't be used on a host, can't be...you get the picture. Reporting parameters ala 2011 are like a neutered/spayed dog - no good for families - oh snap! This is a much broader implementation of "reporting parameters" that I'm talking about. Much more like a database query than a dimensional gag gift.
Need a better example? Let's pretend you've got a shared nested panel family in your door family. Let's say that in that shared nested family you've got some type parameters (can't be controlled by the host!) that govern the lite size or the hardware or something else. What, you need to schedule that parameter in the door schedule which only shows the host families? SOL.
This is an example without a workaround that doesn't compromise the functionality of the family. There are tons of examples with complicated workarounds that at least work, but add difficulty and confusion to the family creation process. That's why #3 is the ability to create a parameter in the host family that instead of controlling a parameter in a nested family is controlled BY a parameter in the nested family. No exceptions to what formulas or parameter values it can be used in, etc... This needs to just work.
No comments:
Post a Comment