Topic: Moving Point now changes elevation?

[Mark]

In prior versions of C3D if I grab the grip of a Point and moved it the elevation of the point would not change. Now in C3D 2013 if I move a point using the grip the elevation changes to zero. Is there a setting I can change to get back the old behavior? OSNAPZ doesn't seem to have an effect one way or the other.

thanks

[mjfarrell]

sugget you turn off 3D Object Snap  (F4)

[Mark]

sugget you turn off 3D Object Snap  (F4)

it was off. thanks though.

[mjfarrell]

what are these points you are moving and why?

[huiz]

In 2013 and in 2012 the behavior is the same, if I move a Point or a Cogo Point with grips, the Z remain as it was.

I don't have your problem, so it is not something new in 2013.

[Mark]

In 2013 and in 2012 the behavior is the same, if I move a Point or a Cogo Point with grips, the Z remain as it was.

I don't have your problem, so it is not something new in 2013.

If you draw a line with both Z values at 0.00 then drag a point over to the line and snap the end point or mid point then check the Z value of the Point. In previous version the point would retain its value and ignore the Z value of the line or curve.

[Mark]

I've been seeing this a lot too. Perhaps the reason I can't 'create a Point'?

[mjfarrell]

Are you running s administrator?

[Mark]

Are you running s administrator?

If you're referring to the OS yes I am. I'm still on XP.

[mjfarrell]

Are you running s administrator?

If you're referring to the OS yes I am. I'm still on XP.

sounds like you may want a repair install

[Jeff_M]

I see the same behavior as Mark. In 2012 the point retains it's Z value when grip edited. In 2013 it takes on the elevation of the object snapped to.

[Mark]

I see the same behavior as Mark. In 2012 the point retains it's Z value when grip edited. In 2013 it takes on the elevation of the object snapped to.

thanks for the conformation Jeff. I knew I wasn't going crazy!

[Mark]

Are you running s administrator?

If you're referring to the OS yes I am. I'm still on XP.

sounds like you may want a repair install

I was thinking the same thing.

[Mark]

I see the same behavior as Mark. In 2012 the point retains it's Z value when grip edited. In 2013 it takes on the elevation of the object snapped to.

Could someone post this on the Adesk news groups please. I would really like to know how to change this behavior.

thanks

[Jeff_M]

I just posted a question about this, Mark. During my testing I encountered the same fatal error you mention above. I sent in the CER and within minutes I had an email from Tech support asking about it. I sent back the exact steps I had just gone through, and mentioned WHY I was doing the test (the change in workflow between 2012 & 2103 point grip editing). So I know it's in their system now.

[Mark]

I just posted a question about this, Mark. During my testing I encountered the same fatal error you mention above. I sent in the CER and within minutes I had an email from Tech support asking about it. I sent back the exact steps I had just gone through, and mentioned WHY I was doing the test (the change in workflow between 2012 & 2103 point grip editing). So I know it's in their system now.

Thank ya sir.

[Jeff_M]

Well, it appears that 2012 is the only version which holds the point's elevation when grip editing. Matt Kolberg tested versions 2009-2013 and reported these findings. I then tested in 2010 and 2011 myself and also found this to be the case. Sinc and Steve Boon also chimed in with similar findings.

It would be nice if there was a setting that we could use to enable/disable this, as I can see where it would be handy for either method to be used.

[Mark]

Any 'news' on this? I'm working on a huge (for me) DTM and it's driving me up the friggin wall.

[BlackBox]

Well, it appears that 2012 is the only version which holds the point's elevation when grip editing. Matt Kolberg tested versions 2009-2013 and reported these findings. I then tested in 2010 and 2011 myself and also found this to be the case. Sinc and Steve Boon also chimed in with similar findings.

It would be nice if there was a setting that we could use to enable/disable this, as I can see where it would be handy for either method to be used.

Jeff, would it be possible (in the mean time, waiting for Autodesk to formally fix this), to use an Event monitor for when a Point3d is Grip Edited, to store the Z prior to Grip Edit, and replace Z after Grip Edit?

It should also be simple enough to add a registry key, and CommandMethod to allow the user to toggle this setting, no?

... Still very new to C#, but conceptually this seems possible (to me).  Perhaps you can clarify.

[Jeff_M]

Renderman, I think this could be done with GripOverrules. But I'm not well versed in them and I don't have much time to play today. Kean and Stephen Preston have posted examples in the past. I'll see if I can check this idea out this evening.

[BlackBox]

I've never heard of GripOverrules... Sounds great, thanks for looking into this!

[Mark]

Renderman, I think this could be done with GripOverrules. But I'm not well versed in them and I don't have much time to play today. Kean and Stephen Preston have posted examples in the past. I'll see if I can check this idea out this evening.

Thank you Jeff.

[Jeff_M]

Renderman, I think this could be done with GripOverrules. But I'm not well versed in them and I don't have much time to play today. Kean and Stephen Preston have posted examples in the past. I'll see if I can check this idea out this evening.

Thank you Jeff.

Happy to try, Mark. However, upon deeper investigation, the grips aren't exposed in the API for the Points. I got what I thought would work (and does work on basic Acad objects) but once the point is selected, all grips disappear so you cannot move it at all with grips. So now I'm off to see what can be done using Renderman's suggestion, but without access to the grips I'm not sure how to limit it to when a point is grip edited. More research is needed...not sure how much time I can spend until the weekend, but I'll try to come up with something.

[BlackBox]

Renderman, I think this could be done with GripOverrules. But I'm not well versed in them and I don't have much time to play today. Kean and Stephen Preston have posted examples in the past. I'll see if I can check this idea out this evening.

Thank you Jeff.

Happy to try, Mark. However, upon deeper investigation, the grips aren't exposed in the API for the Points. I got what I thought would work (and does work on basic Acad objects) but once the point is selected, all grips disappear so you cannot move it at all with grips. So now I'm off to see what can be done using Renderman's suggestion, but without access to the grips I'm not sure how to limit it to when a point is grip edited. More research is needed...not sure how much time I can spend until the weekend, but I'll try to come up with something.

It is unfortunate that yet more Aecc* features are lacking from those already exposed to the .NET API, but I am glad that I at least was able to offer an alternative (albeit unorthodox) method.

FWIW - This may be thinking too much like a LISP-er, but I use a Visual LISP Command Reactor to monitor when a user grip edits objects (using the GRIP_STRETCH Command) to automagically toggle the user's CursorSize from 5% to 100%, perhaps you can translate the obscure LISP dialect into a more refined C# snippet of code?  LoL

[Mark]

Happy to try, Mark. However, upon deeper investigation, the grips aren't exposed in the API for the Points. I got what I thought would work (and does work on basic Acad objects) but once the point is selected, all grips disappear so you cannot move it at all with grips. So now I'm off to see what can be done using Renderman's suggestion, but without access to the grips I'm not sure how to limit it to when a point is grip edited. More research is needed...not sure how much time I can spend until the weekend, but I'll try to come up with something.

My intent was not for you to come up with a solution Jeff. I would really like to hear from Autodesk.

[Jeff_M]

I would really like to hear from Autodesk.

Uh, huh. I have no doubt that what you will hear is that 2012 was broken and it was fixed in 2013, therefor nothing will be done about it. Hence my quest for a solution. Have you logged a support request through the Subscription site?

You can workaround this, although it is a bit slower workflow. When picking the location to move to, use the .XY filter and pick the location, it will ask for the Z, now move back to the original grip and the CogoPoint will then use it's original elevation (provided the styles used for display are set to "Use Point Elevation").

[Mark]

I would really like to hear from Autodesk.

Uh, huh. I have no doubt that what you will hear is that 2012 was broken and it was fixed in 2013, therefor nothing will be done about it. Hence my quest for a solution. Have you logged a support request through the Subscription site?

No, I have not. Not sure I can even get to that site from here. LOL

You can workaround this, although it is a bit slower workflow. When picking the location to move to, use the .XY filter and pick the location, it will ask for the Z, now move back to the original grip and the CogoPoint will then use it's original elevation (provided the styles used for display are set to "Use Point Elevation").

BINGO!! Thanks Jeff. Never thought about using point filters. That will work!