I am going to take a guess here, and say that he is trying to eliminate the combination of VisLISP with regular old LISP
Not quite. I don't like to mix Lisp and ActiveX
if it can be avoided (too many hickups when doing that, at least before r2004) but VL-CMDF is not an ActiveX command. It's a COMMAND function with an improved error handling.
I guess it's due to pure laziness when trying to debug a function where a command goes wrong. When there's an error in a COMMAND, it bombs and continue the command in AutoCAD, whereas VL-CMDF bombs out (depending on the situation, though) and terminates the command in AutoCAD. By going back to AutoCAD and see where COMMAND left you it's rather easy to get a hint of what went wrong.
Try make a faulty COMMAND sequence and check it out. Here's one
(defun C:ARCIRC_C ()
(command "ARC" (setq pt (getpoint "\nArc start point: ")))
(command "CIRCLE" pt 2.0)
)
Command: arcirc_c
Arc start point:
2D point or option keyword required. <-- invokes VLIDE here
Function cancelled; reset after error <-- resetting in VLIDE
Specify second point of arc or [Center/End]: <-- back to AutoCAD
When it errors, at least it's obvious that it didn't finish the ARC command and something went wrong after specifying the first point.
With VL-CMDF it can be a little more difficult.
(defun C:ARCIRC_F ()
(vl-cmdf "ARC" (setq pt (getpoint "\nArc start point: ")))
(vl-cmdf "CIRCLE" pt 2.0)
)
Command: arcirc_f
Arc start point:
2D point or option keyword required.
Invalid 2D point.
nil
Specify end point of arc: *Invalid*
Command:
That an error occurred is obvious, but where? It doesn't even jump back into VLIDE but continues in AutoCAD with a fresh Command prompt. A backtrace tells you nothing.
Of course, the error can easily be found by stepping through the stuff, but as said, I'm too lazy and want an instant bug to crawl out.
When the code is bug free and ready, I don't really care which command is used. That said, there ARE good uses where you deliberately want to proceed with a routine even though an error occurred - which is why VL-CMDF was written in the first place, I guess.