Mike, the key here is that Revit has three very different kinds of "relationship".

Hosted results in an object that moves with it's host, and can itself be moved within the plane of its host. But you can't move a door perpendicular to the wall and have the wall follow. It is a 1 directional relationship, the host driving the object, but the object also manipulates the host, cutting holes, etc.

You can also align or dimension and then lock. This creates a two way relationship. Move either item and the other item moves. This is powerful, but too much use of this approach over constrains the model and causes problems. So you use this for things like clear dimension of a corridor. Something the code requires you maintain. Or centering a window in a room when that is a major design element.

Lastly you have Moves with Nearby Elements. This only works for non hosted component families. A hosted family already has these behaviors defined in the hosting relationship. And system families are so fundamental that you want to discretely define relationships with dimension/align & lock. Moves with Nearby Elements is also one way, the nearby element drives the component, but not the other way around. Lastly, I think this only works with the nearest orthogonal walls, meaning orthogonal to the component. What does all that mean? Well, draw two walls, put a table, two chairs and a floor lamp in the corner, and moving either wall maintains the furniture "group", but you can reposition the furniture relative to each other and the walls at will. If the adjacent wall is cranked relative to the furniture it won't drive it, as their is no implied relationship. For what it is worth furniture and entourage is what I find this useful for. Everything else either doesn't work, or would be better handled with a more "intentional" relationship.

As for the door, we have a ref plane on the swing side of our single doors, driven by a Wall Offset parameter. We can Align and Lock that ref plane to an adjacent wall when needed, and the dimension of the offset can be updated project wide. Yes, if the door is moved the wall follows, but it is worth the risk in this case. OOTB doors don't behave this way, I guess because the need wasn't perceived by the Factory, and because every office is going to have different rules about how it should work.

Sorry, kinda ran off on a tangent there.

Gordon

Gordon,

Love the idea of adding the reference plane to the door family that can be locked to the wall. While I generally chose carefully what I lock, as you mention it's easy to over constrain quickly, I think this is a case where locking the reference plane to the wall would work great.

Move with nearby Elements sucks. Draw a room thats a rectangle. Put a piece of Unhosted furniture in one corner, but not touching either wall. Now move one of those two walls. The furniture moves. Sweet.

Now move the wall farthest away, so its as close to the furniture as the other two walls. Then move it away. Furniture doesnt go with it. Well... its just as close as the other walls now!

And how far does that idiocy stretch? If i move the wall CLOSER, and then i SWC, and you come in and move the latest version of the wall, does THAT count as nearby, even though it ORIGINALLY didnt? How do YOU know which walls were ORIGINALLY considered Nearby?

There ARE answers to these questions, but my point is: Once i saw the ambiguity involved (like so many things in revit) i ****-canned it. I have Constraint views, in our template, and a dimension style CALLED Constraints. if anyone wants to lock ANYTHING, they go do it there, with those dimensions. A fast tool is a great thing. A fast ambiguous tool that causes uncertainty in action, is a terrible thing.

What makes this command even more unpredictable is that if you tick the checkbox in the properties pallette it does not work at all (in v2013 and prior), but if you tick the equivalent checkbox in the Options toolbar it does work. Does that make it predictably uncertain?
I've reported this to Autodesk, but I haven't checked to see if its fixed in v2014.