Page 1 of 1

Point Object Snap wreaks havoc with copied or moved entities

PostPosted: Sat Dec 10, 2005 6:24 am
by JJR
Has anyone had the following issue?
We are currently running Survey 2006, all on fairly new PCs.
Here's the background.
Assume points in the drawing have elevations but have been drawn without the
elevations shown AND not at their real z-values. This being the case, one
could assume a new line drawn to the points, with Point Object Snap (POS)
ACTIVE, would have starting and ending elevations of zero. In fact that is
how it works.
However, with the same point and POS ACTIVE, if I copy or move a line with
an elevation of zero to that point, IT ADOPTS THE ELEVATION OF THE POINT
SNAPPED TO. This will NOT occur though, if rather than using POS, we
specifically snap to the node of the point with the regular CAD command.
(i.e. By typing "nod") The line stays with it's original elevation data. It
appears to be an oversight of the programmers
Unfortunately the result can be a whole lot of inadvertently drawn 3-D
lines. Any reason this can't be fixed? I don't want lines that are copied
or moved to adopt elevations unless I specifically tell them to by having
the points drawn at their real z-value.
If I'm missing something simple, please let me know.

Re: Point Object Snap wreaks havoc with copied or moved enti

PostPosted: Tue Dec 20, 2005 7:50 pm
by Barkley Hensley
I have duplicated what you have described below but I don't know if I
would consider this a "bug". When you use the Point Object Snap, the
program is reading from the coordinate file and not the node in the
drawing. That is why when you use the regular node snap it holds the 0
elevation, because the node is located on 0. I will bring this to the
attention of the programmers but this could have been all by design.
Maybe an option of "Inherit elevation from screen or file?" Lets see
what we can come up with.


JJR wrote:

Has anyone had the following issue?
We are currently running Survey 2006, all on fairly new PCs.
Here's the background.
Assume points in the drawing have elevations but have been drawn without the
elevations shown AND not at their real z-values. This being the case, one
could assume a new line drawn to the points, with Point Object Snap (POS)
ACTIVE, would have starting and ending elevations of zero. In fact that is
how it works.
However, with the same point and POS ACTIVE, if I copy or move a line with
an elevation of zero to that point, IT ADOPTS THE ELEVATION OF THE POINT
SNAPPED TO. This will NOT occur though, if rather than using POS, we
specifically snap to the node of the point with the regular CAD command.
(i.e. By typing "nod") The line stays with it's original elevation data. It
appears to be an oversight of the programmers
Unfortunately the result can be a whole lot of inadvertently drawn 3-D
lines. Any reason this can't be fixed? I don't want lines that are copied
or moved to adopt elevations unless I specifically tell them to by having
the points drawn at their real z-value.
If I'm missing something simple, please let me know.


Re: Point Object Snap wreaks havoc with copied or moved enti

PostPosted: Wed Dec 21, 2005 7:55 am
by JJR
Sounds like a good option, I have not checked to see if other entities
follow suit, i.e. circles or whatever. That would definately solve the
situation. Only reason it was brought up is that we were unaware of the 3-d
affect the command would have. This led to a few issues, but we can work
around it with the knowledge that command reads from the .crd file. Still
an option would be nice.

"Barkley Hensley" <bhensley@carlsonsw.com> wrote in message
news:do95ns$lf0$1@update.carlsonsw.com...
I have duplicated what you have described below but I don't know if I would
consider this a "bug". When you use the Point Object Snap, the program is
reading from the coordinate file and not the node in the drawing. That is
why when you use the regular node snap it holds the 0 elevation, because
the node is located on 0. I will bring this to the attention of the
programmers but this could have been all by design. Maybe an option of
"Inherit elevation from screen or file?" Lets see what we can come up with.


JJR wrote:

Has anyone had the following issue?
We are currently running Survey 2006, all on fairly new PCs.
Here's the background.
Assume points in the drawing have elevations but have been drawn without
the elevations shown AND not at their real z-values. This being the
case, one could assume a new line drawn to the points, with Point Object
Snap (POS) ACTIVE, would have starting and ending elevations of zero. In
fact that is how it works.
However, with the same point and POS ACTIVE, if I copy or move a line
with an elevation of zero to that point, IT ADOPTS THE ELEVATION OF THE
POINT SNAPPED TO. This will NOT occur though, if rather than using POS,
we specifically snap to the node of the point with the regular CAD
command. (i.e. By typing "nod") The line stays with it's original
elevation data. It appears to be an oversight of the programmers
Unfortunately the result can be a whole lot of inadvertently drawn 3-D
lines. Any reason this can't be fixed? I don't want lines that are
copied or moved to adopt elevations unless I specifically tell them to by
having the points drawn at their real z-value.
If I'm missing something simple, please let me know.

Re: Point Object Snap wreaks havoc with copied or moved enti

PostPosted: Wed Dec 21, 2005 6:46 pm
by Barkley Hensley
I have talked to the programmers concerning this and they said that it
should get a zero elevation when the point is drawn with the real z off.
They also indicated they would look into it and see what was going
on. So at this time just carry on with the knowledge that the routine
will read the elevation from the crd file until the programmers get a
chance to get into it.

JJR wrote:
Sounds like a good option, I have not checked to see if other entities
follow suit, i.e. circles or whatever. That would definately solve the
situation. Only reason it was brought up is that we were unaware of the 3-d
affect the command would have. This led to a few issues, but we can work
around it with the knowledge that command reads from the .crd file. Still
an option would be nice.

"Barkley Hensley" <bhensley@carlsonsw.com> wrote in message
news:do95ns$lf0$1@update.carlsonsw.com...

I have duplicated what you have described below but I don't know if I would
consider this a "bug". When you use the Point Object Snap, the program is
reading from the coordinate file and not the node in the drawing. That is
why when you use the regular node snap it holds the 0 elevation, because
the node is located on 0. I will bring this to the attention of the
programmers but this could have been all by design. Maybe an option of
"Inherit elevation from screen or file?" Lets see what we can come up with.


JJR wrote:


Has anyone had the following issue?
We are currently running Survey 2006, all on fairly new PCs.
Here's the background.
Assume points in the drawing have elevations but have been drawn without
the elevations shown AND not at their real z-values. This being the
case, one could assume a new line drawn to the points, with Point Object
Snap (POS) ACTIVE, would have starting and ending elevations of zero. In
fact that is how it works.
However, with the same point and POS ACTIVE, if I copy or move a line
with an elevation of zero to that point, IT ADOPTS THE ELEVATION OF THE
POINT SNAPPED TO. This will NOT occur though, if rather than using POS,
we specifically snap to the node of the point with the regular CAD
command. (i.e. By typing "nod") The line stays with it's original
elevation data. It appears to be an oversight of the programmers
Unfortunately the result can be a whole lot of inadvertently drawn 3-D
lines. Any reason this can't be fixed? I don't want lines that are
copied or moved to adopt elevations unless I specifically tell them to by
having the points drawn at their real z-value.
If I'm missing something simple, please let me know.