Friday, September 17, 2010

#5 - To Share or not to Share, that is the question...

In this case, I'm referring sharing families, not parameters. The problem with sharing a family is that it has so many consequences. It doesn't just allow you to pick from families in the project using a family type parameter. It also makes the families type parameters uncontrollable by the host family, and causes the nested families to show up in schedules and tag upon placement (if that option is turned on). Oh, and once you share you can't go back without a royal PITA. So, you better pray you want all, or none. 


Obviously, this causes conflicts. I'd prefer have a checkbox for each in the family category and parameters dialog. So, I can have it "shared" so that it can be loaded into a host family from a project file. But, I don't have to schedule it or have it tag. Now, when my nested panel family is placed by association with its host door family, I won't get two tags in the floor plan and I won't have to set up a filter in the door schedule just to hide the 157 panel families that came in with my 126 door families (I can count - some of them are double doors and have two panels, so there). Or, what if I want it to only pick from what I load in the family but DO want it to schedule or tag. Or so I can tie Type parameters to parameters in the host family but still get tagging, scheduling, and loading...


What's even more confusing is that the Family Type parameter that controls these derives its shared/non-shared nature from the first family you load when you create it or the first family assigned to it. Shouldn't that be a property of the parameter not of the family? This is why #5 is to re-work shared families and let users control the various different behaviors in the model individually instead of the all-or-nothing we've currently got!

No comments:

Post a Comment