Change system variable, offset, change system variable back
@ВeekeeCZ wrote:
..........
My conclusion is that this is working on 2015+ versions (except Kent's).
I agree. Is Autodesk making such unpredictable products that produce random errors across different machines? I don't think so. Something is happening with user settings or how they are executing the code. That's exactly why I requested a screencast (which I am pretty sure we will not be receiving).
I have tested on 2015, 2017, OP has tested on 2018; and thanks again @ВeekeeCZ for your testing on different version including 2012. Code works on all those machines (except 2012). So I will be seriously shocked if it didn't work on 2016 without user manipulation.
As far as command-s and command goes, their choice depends on the code. In the above c:Buffer code command-s is ideal since there is such minimal code to work with. Let me explain. (Below applies to machines running AutoCAD 2015 and up)
See below
As you can see qleader starts, document evaluator is looking still for arguments, it encounters pline command but this isn't a valid argument for qleader and so is ignored and the final line is printed and now qleader command proceeds. Important thing to note is that LISP code did not halt for command to finish. Now try below.
As you can see the code beautifully waits for each command-s to complete and moves on to next line, and while in the actual command all options are allowed. This is explained by AutoCAD help statement "The command that is being executed must be started and completed in the same command-s function." which some of us have a hard time interpreting. Let's read in entirety The "-s" suffix stands for "subroutine" execution of the supplied command tokens. In this form, AutoCAD is directly called from AutoLISP, processes the supplied command tokens in a temporary command processor distinct from the main document command processor, and then returns, thus terminating the temporary command processor. The command that is being executed must be started and completed in the same command-s function. That's the reason why every command-s is finished before moving on to the next command. Thus explaining why c:Buffer works everytime in re-setting the offsetgaptype variable.
What is this temporary command processor? Let's see below by combining command-s and command.
Again LISP code is paused nicely for command-s to finish and then goes to polyline command but this time does not pause (that's how command works), and prints the line and continues with the pline command. Clearly shows the difference between command-s and command.
Finally, try below but first save anything you need to. Below will successfully enter the temporary command processor through the document processor and freeze acad.
The above is just my understanding based on the help document available here.
I am having a hard time getting hold of 2016 trial version s0 I am still requesting other users to test the code on 2016 and report. I would definitely like to know if 2016 is such a broken piece of software, OR user manipulation was involved to mislead all the other community members.
@ActivistInvestor wrote:
..........In 2015 or later, the behavior should be the same as if you had issued NEXTFIBERWORLD = 0 in older releases.Thanks @ActivistInvestor for sharing that information. Below is a little test with the c:Buffer code with NEXTFIBERWORLD set to ON and OFF on AutoCAD 2015.
You can see that in both the cases the code works fine. I am having a hard time with the screenshot in Post#18. How does the command-s fail without some user manipulation of the offset command. I can present an example here of how one can get that screenshot.
All I am trying to say is intentionally/ unintentionally the offset command has to be manipulated to throw that error. There are no other elements in that command-s line of below code that can cause its failure?
(defun c:buffer() (setvar "offsetgaptype" 1) (command-s "offset") ; no tokens passed, so command name itself is source of error (setvar "offsetgaptype" 0) (princ) )
@Ranjit_Singh wrote:
.... OR user manipulation was involved to mislead all the other community members.
It's hard to know how to respond to such a statement, except perhaps to suggest that any notion that I would participate here with any purpose to mislead anyone is easily enough refuted by directing you to:
Top Solution Authors / View All / All Time
[Let's see -- yes, I'm going to boast a little -- if you manage to rack up 10 more Accepted Solutions than I do every month on average (once in a while you do), you'll catch up to me in about 5 years.]
But I figured out what the difference is. You may choose to consider it "user manipulation," but I consider it "functional enhancement." I've had it in place long enough that it's just background for me by now, so it took me a while to realize. It's not the difference between (command) and (command-s), nor about whether there is an *error* handler defined, either inside or external to any command definition, but the key is the difference between
(command-s "offset")
and
(command-s "_.offset")
[or the equivalent (command-s "._offset") -- either order of underscore and period/decimal works, as it would also in English versions without the underscore character].
I have an enhanced definition of the OFFSET command, in a routine which Undefines the original first. The enhanced version allows changing the Offset distance without exiting the command, including changing between a numerical distance and the Through option. You can try it out -- it's available here. It's because of that Undefinition that I need the period/decimal prefix on the command name in order for the BUFFER command in this thread to work, and it does work when I add that. OFFSET is the only command I have "replaced" in such a way, so if this thread had involved any other command, there would have been no issue.
I notice that in your screencast examples in Post 21, you do include the ._ prefix on command names. If that had been included in Post 3, it would have worked for me all along, but it wasn't in the OP's original, and neither you nor I thought to add it in our suggested alterations.
When I first started getting into (defun)ing custom commands, I was using Architectural Desktop, which similarly Undefined the LAYER command and made its own specialized version. That meant that (command "layer") caused an unknown-command error, and anything I did involving LAYER in a (command) function had to be done with the period/decimal prefix. Since then, I've always included that, as well as the underscore because of the international reach of these Forums, in any kind of custom command definition.
Kent Cooper, AIA 
Kent1Cooper wrote Top Solution Authors / View All / All Time
[Let's see -- yes, I'm going to boast a little -- if you manage to rack up 10 more Accepted Solutions than I do every month on average (once in a while you do), you'll catch up to me in about 5 years.] p>But I figured out what the difference is. You may choose to consider it "user manipulation," but I consider it "functional enhancement............
Sure you have enhanced version of every single command. It took you 96 hrs to remember that? Your memory cells are pretty weak for a top solution Author
it's kind of hard to believe, if not impossible, that all the time while you implied that the error had something to do with command-s or AutoCAD 2016 or that I had a manipulated global error trap, it never crossed your mind that you had modified offset command?
OR maybe it was after Post #23 (the offset command has to be manipulated to throw that error. There are no other elements in that command-s line of below code that can cause its failure?) and @ВeekeeCZ and @cadffm also suggesting that 2016 should work, that you realized there was no way out but to simply accept.
As far as ..........if you manage to rack up 10 more Accepted Solutions than I do every month on average (once in a while you do), you'll catch up to me in about 5 years....
seriously? That just documents your sorry state. There are people here like myself who are learners (see this) and people like us grow. It's only people who are full of it, never learn and never grow. Misleading 100's of other community members to feed your own false belief "Top Solution Authors / View All / All Time" is not only pathetic but also unethical. You remind me of A few good men.
Ron: Did you manipulate offset? You don't have to answer that. I will answer that for you. See post 23.
Ken: You want answers?
Ron: I think I'm entitled!
Ken: Son, we live in a world that has a wall... and I am the top Solution author sitting on top of that wall.
Ron: I want the truth! Did you manipulate offset?
Ken: I did the job
Ron: Did you manipulate offset?
Ken: You're god#@&*ed right I did!
Ron: I suggest the members be dismissed.
