Nearest Osnap doesn't work on Civil contour objects

[Anonymous]

Really weird. This is an intermittent problem. sometimes the nearest snap defaults to end snap only on a civil contour object. the little icon looks like a nearest but when you pick it goes to the nearest end point. Works fine on all other entities.

[Anonymous]

Nearest does exactly what I wish it to drw-cubed, in relationship to CCOs
that is.

Just tested it with LDT 2K4, and it worked like a charm.

Seems you have LDT 2K6 IIRC?

I'll attempt to recall to test this tonight with LDT 2K7, without the
current SP debacle brewing in the "kidding" thread.

--
Don Reichle
"The only thing worse than training your staff, and having them leave is -
not training your staff, and having them stay." 😮
A reminder taken from Graphics Solution Providers' Calendar page
--------------------------------------------------------------------
!! Please discuss whatever we tell you with your SysMgr !!
!! They appreciate staying in the loop 🙂 !!

CivilSeries-2K4
Intel Xeon 3.2GHz 2GB RAM
XPPro 32bit SP2
Nvidia Quadro NVS 285 256MB

"The only Constant is Change".


wrote in message news:5423466@discussion.autodesk.com...
Really weird. This is an intermittent problem. sometimes the nearest snap
defaults to end snap only on a civil contour object. the little icon looks
like a nearest but when you pick it goes to the nearest end point. Works
fine on all other entities.

[Anonymous]

Yea, It works sometimes for me too. I have narrowed it down to the drawing. The issue is in the drawing. It does the same thing on any computer

[Anonymous]

My olde WBLOCK trick may be appropriate then.

Now I wish I could recall the last time I wrote it out in these environs.
:-(

Located it finally from MAR06:

First use Layer State Manager to save the Layer States the way you have them
setup at this moment in time.
Export that Layer State for further use below.
Then for all Layers in this dwg, Thaw and turn them ON.
Then use Qselect to Wblock out each individual Object Type (except XREFs),
and Delete the Object as part of the Wblock process. That way your Qselect
list of Objects shrinks with each Wblock process.
Caveat - don't save the dwg during this process. You'll see why further down
these instructions.
Name these dwgs produced by the Wblock process to the Object Type you've
gathered through the Qselect process.
Once you're finished with all the Objects, and are only left with XREFs,
then close the dwg giving you fits, but don't save the changes. So that you
have another try at it, just in case of error along the way. Or Server
Crash, or PC Crash, or Application Crash, etc. - you get the picture.
Then open a New dwg, and Insert all of the Object Type dwgs produced by the
prior Wblock processes. Check the Explode option as part of this Insert
process.
Import the Layer State from above.
Restore said Layer State.

99 times out of 100 this process will leave whatever entity has gone corrupt
back in the 1st troublesome dwg file. I believe the Qselect process weeds
them out this way. Since they have gone corrupt, it can't select them, is my
guess.

I would claim 100 percent effectiveness for this process, but I've learned
that you can't always cover all the idiosyncrasies along the way. Both
machine and personal.

If you try this - HTH.

--
Don Reichle
"The only thing worse than training your staff, and having them leave is -
not training your staff, and having them stay." 😮
A reminder taken from Graphics Solution Providers' Calendar page
--------------------------------------------------------------------
!! Please discuss whatever we tell you with your SysMgr !!
!! They appreciate staying in the loop 🙂 !!

CivilSeries-2K4
Intel Xeon 3.2GHz 2GB RAM
XPPro 32bit SP2
Nvidia Quadro NVS 285 256MB

"The only Constant is Change".


wrote in message news:5425080@discussion.autodesk.com...
Yea, It works sometimes for me too. I have narrowed it down to the drawing.
The issue is in the drawing. It does the same thing on any computer