Even when AutoCAD is running without fibers, the distinction between “application context” and “document context” remains, as manifested in the return value of AcApDocManager::isApplicationContext, but the application context is now “switched to” by “returning out of” the document context logic.
What that means for AutoCAD users and your application is that one can no longer switch active documents with active commands and/or LISP expressions and switch back and resume those commands.
Fiberless document switches are done only after all commands and LISP expressions in the previous document are ended. After making a call to a function that is intended to result in a document switch, the application must then return, and AutoCAD will complete the document switch. Document switching requests include the closing of an active document or open/creation of a new document. After such a request is made, the input throat is disabled until AutoCAD completes the document switch. This can lead to differences in the timing of some reactor callbacks pertaining to document deletion.
When defining commands, setting the ACRX_CMD_SESSION flag still signals that the command should be run in the application context, which still effects how some API functions behave. The execution of such commands is internally delayed compared to fiberized operations if LISP or another command is active, so some reactor callbacks may be out of line. When no other commands or LISP is active, the difference in execution timing should be negligible.
Given this summary of MDI API changes, here is the impact on the specific following MDI API functions, all defined in class AcApDocManager. For brevity, the behavior differences are listed in comments preceding each function and describe the different behavior you will see when running fiberless AutoCAD.
class ADESK_NO_VTABLE AcApDocManager : public AcRxObject
{
public:
// Still has meaning in fiberless operations, but the timing of when
// the system is in application context differs in two significant ways:
// 1. when running fiberless, CLI prompts issued in active commands never
// leave document context. In fiberized operations, all prompts
// enter and leave application context on every event.
// 2. See executeInApplicationContext function, it literally forces
// this function to return true, even with active document-related
// logic on the stack. This usually works to everyone’s advangate,
// but active document switch requests are deferred until all command
// and LISP expressions, and it allows one to use appContextCloseDocument,
// but in this context, active command logic will likely crash
// AutoCAD if the closed document is active.
virtual bool isApplicationContext() const = 0;
// If activate is true, the actual activation will not occur until after
// all commands and LISP are ended, and keyboard/mouse/script input is disabled.
virtual Acad::ErrorStatus setCurDocument(AcApDocument* pDoc,
AcAp::DocLockMode = AcAp::kNone,
bool activate = false) = 0;
// Actual activation will not occur until after all commands and LISP are ended
// After calling activateDocument, all keyboard and mouse input is disabled
// until after the document switch finally occurs.
virtual Acad::ErrorStatus activateDocument(AcApDocument* pAcTargetDocument,
bool bPassScript = false) = 0;
// If activate is true, the actual activation will not occur until after
// all commands and LISP are ended, and keyboard/mouse/script input is disabled.
virtual Acad::ErrorStatus sendStringToExecute(AcApDocument* pAcTargetDocument,
const ACHAR * pszExecute,
bool bActivate = true,
bool bWrapUpInactiveDoc = false,
bool bEchoString = true) = 0;
// During document creation, the new document is no longer activated until
// its initialization is complete. In fiberized operations, the new
// document is activated very early in initialization.
virtual Acad::ErrorStatus appContextNewDocument(const ACHAR *pszTemplateName) = 0;
virtual Acad::ErrorStatus appContextOpenDocument(const ACHAR *pszDrawingName) = 0;
ACCORE_PORT Acad::ErrorStatus appContextPromptNewDocument();
ACCORE_PORT Acad::ErrorStatus appContextPromptOpenDocument();
virtual Acad::ErrorStatus newDocument() = 0;
virtual Acad::ErrorStatus openDocument() = 0;
//
// Caution: This function immediately destroys the active document and
// a lot of related data when called from application context, even if it
// is artificially set by using executeInApplicationContext.
// Use closeDocument whenever it will work for you, it queues up a request
// to appContextCloseDocument to be performed at a safer point of execution.
ACCORE_PORT Acad::ErrorStatus appContextCloseDocument(AcApDocument* pDoc);
virtual Acad::ErrorStatus closeDocument(AcApDocument* pAcTargetDocument) = 0;
// Essentially forces the system to behave as if in the application context, even
// if a document has active commands. See the note on appContextCloseDocument,
// which is especially dangerous when invoked from logic invoked through this
// function.
virtual void executeInApplicationContext(void (*procAddr)(void *), void *pData ) const = 0;
};