Disable DropGEOM

[BlackBox]

Sorry if i wasn't clear. I don't work through the xref. It's just the easiest and most prevalent example of the problem. I agree that locking the layer the xrefs are on would help that problem and the command reactors solution sounds interesting. It is also easy to tell that the xref has been moved by listing the properties and setting x,y, and z back to 0. But an active object (say a surface object, or even worse, a pipe object) that is live in the drawing is susceptible to the same problem.

i would prefer to use move (a deliberate action) to dropgeom (a possible unintentional action) to do something with such repercussions.

We are in complete agreement that DROPGEOM should be able to toggled.

That said, I'm merely trying to offer some examples of what I do for my own production work, in the event that it helps you as a workaround here.

As for Surfaces (DREFs) vs XREFs - they're both references, and I approach them the same in kind. A Surface is brought in via Command, the pre-defined layer is created/set as active, the Surface is referenced, layer locked, and my previous layer is restored. Surface-related Commands fire my Reactor, which programmatically unlock the layer for those Commands and restore the lock when done, in order to prevent OOTB, vanilla 'modify' Commands from affecting same (unless I choose to manually unlock said layer[s] first)... This mitigates any accidental modification to reference objects (DROPGEOM or otherwise), whilst allowing me to work with them for the active document's inquiry needs, etc.

[Edit] - Just pointing out that this issue you're experiencing, is ultimately caused by unintentional left mouse button use... Just click the button, instead of holding it down, and no change to your workflow is needed. Haha

Cheers

[mderr904698]

no.. thanks for the ideas. The command reactors are probably too advanced for our office (i think they would still be on LDT if not for me) but I may look into it farther if it becomes a problem.

it can also be invoked on the right click. and i think the combo of left clicking to select then right clicking to bring up the context menu. Also, right clicking to add vertex will do it. It's more the case that i'm faster than the program can to keep up to at times.

[BlackBox]

no.. thanks for the ideas. The command reactors are probably too advanced for our office (i think they would still be on LDT if not for me) but I may look into it farther if it becomes a problem.

No worries; I've posted code for this multiple times, and can provide a working example if helpful.

My reason for going this 'far', was to allow users to just do their work, using any native Command, Menu, Button, etc. and the 'standard' would be handled for them - more energy focused on a good design, less time spent on standards... Once in place, you really forget that it's there, until your company changes standards (again?)... It just works.

... It's more the case that i'm faster....

Going too quickly, is never the right answer... Take your time, and do it right.



#TWSS Haha

[tewjoe569872]

How about a longer delay(or variable) on first click and hold before drag and drop? Seems to solve all problems.