What controls window family origin when placed in elevation views?

[dbroad]

The out of the box windows seem to drag about the center of the window when placing in elevation views.  I can't seem to get my window family to drag by any particular point.  Some changes cause the drag point to be above the window and others below the window.  It's not a big problem - more of an annoyance.

[SteveKStafford]

Yes, roughly the "center" of the opening is where the cursor is but you ought to see it recognize when the window is at the correct elevation based on the sill height. The placement of windows and doors is assumed that fine tuning will happen secondarily...as if saying, "let's agree we need a few windows here and we'll sort out their spacing next"...

[Sahay_R]

@dbroad  - to set up a pasrticular drag point, try this - place intersection reference planes where you want the drag pint to be. In the Properties of the reference Planes, make sure that Defines Origin is checked. 

[SteveKStafford]

Two reference planes in plan may define origin and one in elevation. By default the Center (Left/Right), Center (Front/Back) reference planes are the origin in plan. Most the of the windows I'm familiar with don't have a reference plane set to origin in elevation.

[dbroad]

Thanks for trying to help. I've tried pinning and setting the origin. I've tried top, middle, left, right, and bottom, reloading and trying again. Here is the problem family.  See what you can do.  It's called an Access door but since it is intended to use in the foundation space, it made more sense to make it a window family.  When I try to attach it, it immediately removes the attachment when I try to post.

[SteveKStafford]

You need to zip the file to attach it...yeah that's weird.

[ToanDN]

You are working with Revit the way you used to work with AutoCAD. It would be much more efficient to place windows roughly where they need to be then use dimensions and/or align tool to set them in place.

[dbroad]

Here is is.

[dbroad]

I don't expect perfection but it's just plain annoying when the cursor is 3 feet from the window in any random direction.

[ToanDN · Accepted solution]

Try this.  I set the reference line and swing lines to not reference.

[dbroad]

Thanks for that help.  I have noticed these things after further experimentation:

1. It's possible to pin two parallel reference lines, which shouldn't be possible IMO.  For example, if two pinned parallel planes also have a distance dimension parameter, changing that parameter understandably causes errors and a cycle of constraint removals that is unpredictable.
2. If the bottom reference line is set as the origin, the window drags about its CL when being placed in elevation.
3. If the center top/bottom reference is set as the origin, then the window drags about the window top.
4. If the top reference is set as the origin, then the window drags half the window height above the window.
5. Some reference planes, if not pinned have a "not pinned" symbol when selected. Others do not, whether or not they are marked as not a referenced or some named, weak, or strong reference.  It seems to remember if any reference plane was ever pinned. There doesn't seem to be a way to remove the pin toggle property once added.
6. If a reference plane is marked as an origin, it doesn't also need to be pinned, even though that is the recommentation. If the bottom reference plane is pinned but the center is the origin, no errors are generated when the family height parameters are modified in the project context but they cause overconstrained messages to show up in the family editor.

[SteveKStafford]

1) It's possible to pin two parallel reference lines, which shouldn't be possible IMO.  For example, if two pinned parallel planes also have a distance dimension parameter, changing that parameter understandably causes errors and a cycle of constraint removals that is unpredictable.

Pinning isn't "aware" so it doesn't care what you decide to pin. The action merely tells Revit you don't want this thing to be moved.

2) If the bottom reference line is set as the origin, the window drags about its CL when being placed in elevation.

The stock windows don't have a reference plane assigned to origin in elevation so most "behave". That suggests to me defining one as origin is not "required".

3) If the center top/bottom reference is set as the origin, then the window drags about the window top.

See previous comment

4) If the top reference is set as the origin, then the window drags half the window height above the window.

Ditto...

5) Some reference planes, if not pinned have a "not pinned" symbol when selected. Others do not, whether or not they are marked as not a referenced or some named, weak, or strong reference.  It seems to remember if any reference plane was ever pinned. There doesn't seem to be a way to remove the pin toggle property once added.

Elements in general do not carry a pin icon until they have been pinned the first time. There are some nested elements like curtain grids and mullions that have a "pin" but they indicate a nested parent/child relationship to the host element.

6) If a reference plane is marked as an origin, it doesn't also need to be pinned, even though that is the recommendation. If the bottom reference plane is pinned but the center is the origin, no errors are generated when the family height parameters are modified in the project context but they cause over constrained messages to show up in the family editor.

Pinning is separate constraint. The notion of pinning a reference plane can help define how a family should flex, for example, from Center outward or from left to right. Pinning the left reference plane can ensure the family flexes toward the right while pinning another reference plane is likely to conflict with a parameters intent. The family editor is not a shop drawing environment so adding dimensions with a proper drawing in mind is not appropriate.