Hi Gile,
Thank you for the information. It was a good read. I do not know about anyone else but I would certainly be interested in helping fund a kickstarter campaign for you to start writing a book on C# and the AutoCAD .net API! It is something for you to seriously think about!
I do not know about anyone else but I would certainly be interested in helping fund a kickstarter campaign for you to start writing a book on C# and the AutoCAD .net API!What book? Is exist some content of this?
Hi Gile,
Thank you for the information. It was a good read. I do not know about anyone else but I would certainly be interested in helping fund a kickstarter campaign for you to start writing a book on C# and the AutoCAD .net API! It is something for you to seriously think about!
Second That!
What book? Is exist some content of this?
What book? Is exist some content of this?
No book yet Andrey. I am trying to convince gile to write one. I would happily help fund it through a crowd sourcing campaign such as Kickstarter or something similar.
Gile, I believe that you put too much emphasis on your "supposed" language handicap. You explain things in english much better than I ever could and I have been speaking it my entire life.
So, just a question: to let the user complete command inputs, is it safe to just call Command() as below (which seems to work fine) ?
// acedCommandS: syntax-compatible replacement of acedCommand,
// use for "full commands", not partial ones.
// This command essentially begins with its own
// private command line processor, initialized at
// the "Command:" prompt. The commands are executed
// in the same manner as with acedCommand, except that
// when the supplied input has all been executed,
// the private command line processor is deleted
// and the previous command line processor is unchanged
// from when the call is made. modality and
// transparent "builtin" commands may not be nested.
// acedCmdS
//
// Does the same thing with the same restructions as acedCommandS,
// with a resbuf chain rather than a veriable arguments list.
// Two more supplied parameters are intended for future use.
// acedCommandC, acedCmdC:
// “coroutine” relationship with calling command processor.
// Queues up the resbuf chain for feeding to the
// calling command processor and stores the “returning”
// callback function pointer and data pointer.
// In the text here, they will be collectively
// referred to as "acedCmdC", which in fact is
// the common implementation. "acedCmd" will represent
// the corresponding legacy command functions.
//
// After making call, caller must return from its
// command (or defun/regfunc) entry
// point to allow the command processor to process the
// pending command input. Once done with that input,
// AutoCAD will call pReturnFcn, with pReturnFcnParams
// passed in.
//
// There are some common rules for the use of both acedCmdC
// and acedCmd within a recognized application callback
// (specifically, these functions are only operative within
// specific AutoCAD contexts:
// - a command, registered in ARX via AcEdCommandStack::addCommand
// - a LISP invocation of a function registered via acedDefun
// (and/or acedRegfunc).
// - a coroutine callback passed in from acedCmdC
// - Evaluation of LISP (command) statement evaluation.
// - builtin commands (plus AcEdCommand commands with the
// ACRX_CMD_NONEWSTACK flag set).
// - Session Fiber Commands (or Application Execution Context)
// - Transparent commands, executed at an input prompt of another
// command in progress (Regardless of builtin or ARX-registered)
//
// 1. acedCmdC may be invoked from non-LISP calling contexts
// regardless of the $FIBERWORLD
// setting, (the exclusion from transparent commands remains).
//
// From LISP contexts where acedInvoke() is active (i.e. acedDefun'ed
// functions being called from LISP),
// acedCmdC may only be invoked when $FIBERWORLD is 0.
//
// acedCmd, in comparison, cannot be invoked unless $FIBERWORLD
// is 1, if done, it will return an error status. It also
// cannot be invoked from builtin commands, nor transparent commands.
//
// Therefore, function logic running in an acedDefun/acedInvoke
// context should test acedFiberWorld to determine whether
// to run acedCmd or acedCmdC is permissible. Notice that
// acedCmdS is safe to run in this context regardless of the
// $FIBERWORLD setting.
//
// 2. While it is not a destination in one's migration,
// Command and defun'ed function logic (but not coroutine callbacks,
// described next) may invoke acedCmd any number of times,
// but after making a call to acedCmdC, the function must
// return without making a call to either acedCmdC nor acedCmd.
// If such a call is made, the resbuf chain previously supplied
// by acedCmdC will be replaced with the subsequent chain.
// acedCmd will return an error status and take no action.
// 3. Coroutine continuation functions may call acedCmdC,
// but use of acedCmd will return an error status
// and no action.
// 2. acedCmdS may be used in any of these contexts (and many more)
// and at any time within these contexts.
// It is unobvious to invoke acedCmdS
// after calling acedCmdC and before returning to have its
// input procssed, since the acedCmdS will be executed
// synchronously, but it would work.
// 3. Repeated calls to acedCmdC without returning for processing
// in between will simply erase the earlier acedCmdC contents.
// In other words, only one call will count before returning,
// so don't bother making multiple calls.
// 4. Commands and LISP expressions which use different mixes of
// acedCmd, acedCmdC and acedCmdS may invoke each other
// without regard to the makeup of the other command/expression.
// Command processor modality restrictions will still apply
// such as no nesting of nontransparent commands nor transparent
// commands.
//
// WARNING: support of these functions in logic operated through
// invocation of functions registered via acedDefun
// is incomplete in ACAD 2011.
//