Lisp help

[bgraverholt]

(defun c:brkl ();;; command name
(setq centerpoint (osnap (getpoint "Center Point: ") "int"))
(command "circle" centerpoint 0.0625 "");;; Get center point from user
(command "trim" "LAST" "" PAUSE "") ;;; Ask
(command "erase" "PREVIOUS" "")
)

This my lisp that I created so far. What it does is puts a circle on 2 intersecting lines and trims out the line that you select and deletes the circle. But instead of selecting the line I want it to trim I would rather have it automatically select a point between the center point and one of the quadrants. Which that is where I am stuck on trying to figure out how to select a point between the center point of the circle and the quadrant. Just recently started creating lisp so this lisp probably dont look that great haha. Thanks in advance for your help!

[Kent1Cooper]

The simplest way to get the points halfway between the center and the quadrant points of the Circle is probably to use (polar) to find locations at specified directions, using half the Circle's radius as the distance.  The (polar) function wants its directions specified in radians, so this is what it would look like:

(polar centerpoint 0 0.03125); returns point halfway from center to right quadrant

(polar centerpoint (/ pi 2) 0.03125); to top

(polar centerpoint pi 0.03125); to left

(polar centerpoint (* pi 1.5) 0.03125); to bottom

There are other ways that would take more code but be equally effective.

[bgraverholt]

That worked perfectly thank you!!! Lets just say what if one of the lines is an arc and the arc doesn't land on that half way point? Would that be difficult to do?

[Kent1Cooper]

---

@bgraverholt wrote:

That worked perfectly thank you!!! Lets just say what if one of the lines is an arc and the arc doesn't land on that half way point? Would that be difficult to do?

---

If it's within Osnap-Aperture-box-size range of that point, you could try this [for the one to the right]:

(osnap (polar centerpoint 0 0.03125) "_nea")

[hencoop]

"Just recently started creating lisp so this lisp..."

As a general rule you should avoid using the COMMAND function, especially when a pause for user input is required.  In AutoCAD 2015 significant changes to how the COMMAND function operates have been made subsequent to Microsoft's elimination of their support for fibers.  Autodesk recommends that you use either COMMAND-C or COMMAND-S; however, COMMAND-S, which is what is needed to pause for user input, is very complicated to implement, so much so that Autodesk recommends using .NET to code for it instead of Autolisp.  I am still trying to recode the few instances where I still use the COMMAND function and I haven't solved them yet.  I've left them for now but I'll need to finish them soon because I can't use 2015 until I do.  My improper use of the COMMAND function in 2015 causes hard crashes that even skipped the error reporting function of AutoCAD.  I'm back to 2014 until this is resolved.

[bgraverholt]

Is there a reason to why I have to be zoomed in for either of the ways to work?

[Kent1Cooper]

---

@bgraverholt wrote:

Is there a reason to why I have to be zoomed in for either of the ways to work?

---

Probably the reason for that is that in any select-an-object step in a command, AutoCAD "sees" the last thing drawn that falls within pickbox [even if the "picking" is coming from a positional calculation rather than from the User actually picking there with a mouse button], and that may not always be the object you want it to find.  So how far in you need to be Zoomed depends on the setting of the PICKBOX System Variable [the default is 3 pixels] and the particulars of what's drawn in the immediate area, and in what order.  You could certainly lessen the degree to which you need to be Zoomed in by having the routine temporarily set PICKBOX to 1, provided you build in the setting of it back afterwards.  Similarly, anything involving Object-Snapping relies on the size of the APERTURE System Variable setting, which you can also change if it makes sense for the purposes of a particular routine.

[Kent1Cooper]

---

@hencoop wrote:

As a general rule you should avoid using the COMMAND function, ....  I am still trying to recode the few instances where I still use the COMMAND function and I haven't solved them yet.  I've left them for now but I'll need to finish them soon because I can't use 2015 until I do.  My improper use of the COMMAND function in 2015 causes hard crashes that even skipped the error reporting function of AutoCAD.  ....

---

It is only within an *error* function in 2015 that you can't use the (command) function [and even there, you can if you go through some other shenanigans].  You don't need to change all your other (command) functions.  See Help for the (command-s) function for a discussion of the differences -- (command) still has its uses.

[hencoop]

It is my understanding that typically it is ill advised to use the command function within an error function.

What I didn't say is that my problems are related to the MDI API and trying to open drawings using the command function in incomplete or coroutine style input where multiple parts of the total command input are issued in a sequence of command functions.  I'll need to either eliminate my use of the command function this way or figure out the proper way to use COMMAND-C which I gather is rather difficult from conversations I've seen on the subject.

BTW, I got it wrong in my OP.  COMMAND-C is the bugger to properly implement.

Here is a devBlog snippet from http://adndevblog.typepad.com/autocad/xiaodong-liang/ that informed me on the subject (emphasis mine, made for an internal memo):

"For this release, we’ve re-architected AutoCAD to completely strip out the use of Fibers and Fiber switching. Fibers are an old technology used in Windows that Microsoft stopped supporting several years ago. AutoCAD made heavy use of fibers and they are what allowed users to switch easily between drawings without interrupting commands. You’ve probably all seen this in action in old versions of AutoCAD – start a LINE command in one drawing, switch to another and draw a CIRCLE, then switch back to the first drawing and the LINE command is still active.

But using fibers was causing a lot of problems for us that we were spending more and more effort working around. For example, the .NET Framework has never supported Fiber Switching, and this is why when you switched documents in AutoCAD when debugging a .NET application, you’d often find that Visual Studio would fail to stop at a breakpoint– or it did break, but couldn’t display your code. That was Visual Studio getting confused by AutoCAD switching Fibers. You won’t experience that problem in Longbow now that we’ve removed Fibers. It also allows us to expose more of the ObjectARX SDK to .NET – the most exciting of which is that we now have a .NET version of acedCommand ((command) in LISP). That wasn’t possible before due to the problems caused by Fibers.

That means ObjectARX has more significant migration requirements. There are two migration areas of concern: the MDI API and use of acedCommand/acedCmd. Then you’ll have to make changes. How big a change depends on how you’re using it.

If you’re passing a complete set of command tokens to the AutoCAD commandline, then all you have to do is add an ‘S’ to the end of acedCommand or acedCmd. S stands for subroutine. This is when you’re sending an entire command, and not pausing for user input.

If you’re sending a PAUSE, or if you’re sending an incomplete set of command tokens (for example starting a line command and leaving it for the user to finish) then you have a lot more work to do. In this situation, you’ll be using acedCommandC – the coroutine version of the command – and you’ll now have to pass a pointer to a callback function as a command parameter. It’s a lot more complicated – so much so that you might even consider migrating your code that needs this to .NET instead."