Community
I'm trying to figure out whether these are fundamentally any different than AutoCAD's built-in .X and .Y coordinate filters [and all the other possibilities: .Z and .XY and .XZ and .YZ].
Kent Cooper, AIA 
@process_solutions wrote:They are different only in that only 1 pick point is necessary when selecting a final coordinate. Rather than selecting for a filter then specifying the remainder of the coordinate, the remainder of the coordinate is inferred from LASTPOINT which is usually established when you specify a base point.
....
Yeah.... In the interim, I managed to realize that advantage.
I wonder whether the "priming" problem might have anything to do with the fact that you have a command defined that loads a file that contains and calls up a different definition of a command with the same name, within the running of the other definition of that command name. I don't know, maybe it's valid, but that kind of recursiveness always makes me nervous.
If you're having things loaded automatically anyway, maybe you should just load the full routines instead of the ones that call for loading them [they're not all that much longer, and not much of a "load" on AutoCAD], and skip the middle-man. Or, you could try this:
Combined into one Lisp file called XYOF.lsp:
(defun C:XOF ....
)
(defun C:YOF ...
)
Then, in acaddoc.lsp or some place:
(autoload "XYOF" '("XOF" "YOF"))
Then it still won't load the file at all unless and until one of those commands is called for. And since there's no possible conflict in command names, it should get around your initial problem, if that conflict has anything to do with it.
Kent Cooper, AIA
@process_solutions wrote:I have created some custom OSNAPs and have them defined for transparent invokation ....
....I am sharing my groovy snaps - They work great for Electrical Schematic work, Diagrams etc.. especially when you are stretching geometry to match other geometry.
....
They are kind of groovy, after all, though I noticed a few things....
It's not necessary to save the final coordinates to a variable and then call that variable for the function to feed the result out to AutoCAD. The return from a (defun) is the last thing that happens in it, so if that's the calculation of the final coordinates, you can just let the calculation feed its result out, and forget the variable.
It doesn't seem desirable [to me, anyway], and it's certainly not necessary, to restrict YOF to using 0 for the end-result Z coordinate. What if you were drawing a Line from some place with a non-zero Z, and you wanted the next endpoint to use that Z coordinate, just as it does the X coordinate, from the previous point?
Setting OSMODE to 0 turns object snap really OFF off, dumping your current combination of modes. But it's possible to have the routine check whether running Osnap is on, and if so, do the equivalent of hitting F3, that is, turn off the running aspect, but keep the combination of modes you have set. Then you can restore that just by hitting F3, and don't need to pick them all from the dialog box again. That seems especially important in this situation, where Osnap needs to be left not running [at least, I couldn't figure out a way to turn it back on under the circumstances, since that would need to happen after the routine has ended and fed its results out to whatever command is running].
You can shortcut (car (cdr ...)) by using (cadr ...) to get the second item in a list [the Y coordinate of a point].
And I figured there might as well be versions available for the other coordinate possibilities that AutoCAD's coordinate filters offer: Z, XY, XZ, YZ.
So I put together the attached. I used NX, NY, etc. as command names, the N being for the Next coordinate(s), since it seemed more apparent [to me] that way that it's always working in relation to the previous point, and not "out of the blue" as AutoCAD's coordinate filters do. [Besides, it's one less letter to type!] And the prompts contain a reminder that other coordinates will be the same as the previous point (@). I also consolidated repetitive elements into sub-routines.
I have added this line to my acaddoc.lsp file, to make them all available, but to not load the file unless and until one of the commands is called for:
(autoload "NextXYZCoord" '("NX" "NY" "NZ" "NXY" "NXZ" "NYZ"))
Kent Cooper, AIA
@process_solutions wrote:Thank you VERY much good sir for your excellent solution.
On my wishlist for this is how have the invocation of this not only pass the coordinate to the active command, but to then also restore the OSMODE to whatever it was before Xof or Yof was invoked. ....
[Looks like yours arrived while I was writing mine....]
I agree -- that would be preferable. See my NextXYZCoord.lsp attached to my previous post for a way to at least make your prior Osnap mode combination, whatever it is, restorable by just hitting F3, rather than using a menu item that sets it to a predetermined combination that might be different from what you had going.
I tried several ways to do what you're asking, by leaving Osnap on and trying to override it in the return of the function. One was to use the (osnap) function on the calculation of the final coordinates:
(osnap (...final coordinates...) "_none")
But though that will determine a point ignoring any running Osnap modes, once the end of the (defun) is reached, and it feeds that point out to the command that's running, if Osnap is on, it still applies it to that result. The same is true with the other approach I tried, which was to define them as functions, not commands, and then they can be "transparent" even if you use the (command) function in them, so I was hoping to use that to feed the final coordinates out to the surrounding command:
(defun NX (...); <-- without the C:
....
(command (osnap (...final coordinates...) "_none"))
)
They would need to be invoked in parentheses, rather than with leading apostrophes -- (NX). But unfortunately, that has the same problem that the (defun C:NX ...) approach has.
And you can't reset OSMODE inside the routine at the end, because that number is what will be fed out to the surrounding command, not the coordinates that have been calculated.
If I think of some other approach, and find it works, I'll surely post it here.
Edited: HERE IT IS! I was doing the (command) feed-out thing wrong; this approach works:
(command "_none" (...final coordinates...))
The attached uses that approach. The functions need to be used with parentheses, but if you're putting them in menu items/toolbar buttons, that shouldn't matter.
Kent Cooper, AIA
![Autodesk Design & Make Report](https://forums.autodesk.com/t5/image/serverpage/image-id/1350519iCB55845EBFC43016/image-size/large?v=v2&px=999" "Autodesk Design & Make Report")
