Object Snap vs Keyboard Priority

Paul Spears

In Autocad, there are options to have keyboard priority over object snaps.  I can't find the same options in Bricscad.

I am having issues when trying to input relative coordinates or polar coordinates in the command line.  The object snaps override the keyboard entry.

I am having similar issues with some lisp routines where lines need to be input using relative or polar coordinates, but the object snaps are overriding.

Any suggestions?

Greg Skelhorn

For the lisp routines you can prevent the snapping by using the OSMODE variable.

(setq osm (getvar "OSMODE"))
(setvar "OSMODE" 0)
... do stuff
(setvar "OSMODE" osm)

but don't forget to restore the OSMODE in your error handler.

For interactive commands I use F3 to toggle snapping on and off.

How can you control this behaviour in Autocad? I thought the object snapping priority over commands in lisp routines was a change made to be compatible with Autocad...

John Gaunt

Apparently so, but the Acad osnap behavior must have gone from overidable in lisps, to unpredictable.

Paul Spears

Thanks Greg!I figured I might need to do something like that with the lisp routines. It is probably good coding practice anyway.I use F3 as well, but am not acustomed to doing it during a command.To control the behavior in autocad... Options-> User Preferences tab -> Priority for Coordinate Data Entry... choose "keyboard entry"Perhaps I am old school in my settings... I still have my "right click" as "enter" rather than pop-up windows.

Pieter Clarysse

Hello all,

On Bricscad, coordinates entered with lisp (command) or sds_command, will be snapped according to OSNAP. This behavior can not be modified.

As far as I know, coordinates entered on the keyboard, in any way, are never snapped. This also can not be modified today in Bricscad. We will  investigate this setting in acad and see what we can do to support it.

@Paul: please submit a support request about the issues when trying to input relative coordinates or polar coordinates in the command line: if you could add a more detailed description of such an issue, and a reproducable scenario, we will be glad to fix it.

Knut Hohenberg

@Greg and Paul

IMHO, it's better to deactivate the running osnap in lisp routines (same as F3) than to set it to none and back to a saved value, which needs an error handler and therefore (at least in acad) isn't completely reliable. You might want to define functions for this (unless you have a perfect memory), e.g. as follows :

 

 

(defun osnap_on ( / rosnap) (setq rosnap (getvar "OSMODE")) (if (> rosnap 16383)  (setvar "OSMODE" (- rosnap 16384)) ))(defun osnap_off ( / rosnap) (setq rosnap (getvar "OSMODE")) (if (< rosnap 16384)  (setvar "OSMODE" (+ rosnap 16384)) ))

 

 

John Gaunt

F3 is ok if you remember to press it early enough, but when a lisp which sets Osmode to 0 is interrupted, the original setting is lost.

I use a small routine, actually created to measure distances, to return it.

It's on the F12 key - (load"hfar");hfar

(Defun C:hfar (/ b c)
(SETVAR "OSMODE" 255)
(setq b (getpoint "\nFirst point: ")
c (getpoint b "\other point: "))
(COMMAND "dist" b c)
)

Roy Klein Gebbinck

@ Knut

An obvious disadvantage to your approach:
A user who has switched off ESNAP before starting a lisp-function that uses (osnap_on) will end up with ESNAP having been switched on.

Knut Hohenberg

@Roy

Hmm, I don't think so. Nothing keeps you from using an error handler additionally - but should this one get interrupted (don't know whether this may happen on bcad, on older acads it did), the user has just to press F3, while otherwise openening the settings window and restoring the wanted mode would be needed...