Среда программирования Библиотеки C++ (стр. 72 )

Много-документные команды

Команда много-документа позволяет пользователям переключать документы при отобранных подсказках пользователя, в то время как команда остается в контроле. Способность иметь единственную команду остается активной поперек документов, очень сложен. В точке выполнения, когда пользователь выбрал, другой документ, чтобы переключить к, все документы голосует для ввода. Они поэтому имеют потенциально запутанные установленные состояния командного процессора, включая возможно вложенные команды, выражения AutoLISP, сценарии, активные, и все в произвольном порядке вложения.

Не может легко определять, уже не говоря о прививают, подходящие элементы одного состояния в другой без главного усилия. Вместо этого, лучшая стратегия - для приложения, чтобы сохранить контроль поперек указанных пользователем выключателей документа, даже если приложение должно быть осуществлено как различные команды в различных окнах. Тогда, все прикладные потребности - механизм к цепным отдельным командам, выполняющимся в различных документах, и контроле, которые командуют, чтобы начаться при изменении{*замене*} документов.

Чтобы синхронизировать действия множественных команд, осуществьте реактор, который перегружает следующие AcApDocManager реакторные функции:

virtual void

documentActivated( AcApDocument* pActivatedDoc );

virtual void

documentToBeDeactivated( AcApDocument* pDeActivatedDoc );

DocumentToBeActivated() реакторная функция может также использоваться, но это происходит прежде, чем документ активизирован. Контекст документа не был установлен в этом случае.

Эти повторные вызовы вызваны всякий раз, когда пользователь нажимает на различный документ, чтобы активизировать это. Реакторы должны только использоваться на AcApDocManager, когда в начальной команде как раз перед запросом ввода пользователя, в точке, когда переключение документа должно быть поддержано. Реактор должен быть удален, когда любой или все такие подсказки закончены или отменены. От повторного вызова, вызовите:

virtual Acad::ErrorStatus

sendStringToExecute(

AcApDocument* pAcTargetDocument,

const char * pszExecute,

bool bActivate = true,

bool bWrapUpInactiveDoc = false) = 0;

Эта функция стоит в очереди строка, которую нужно интерпретировать следующий раз, указанный документ активизирован. Строка должна типично быть обращение команды (мы назовем это вторичной командой), но можем также быть выражение AutoLISP, фрагмент команды, или лексема меню. Строковый предел - 296 байтов, так что более длинные последовательности должны быть осуществлены как команда SCRIPT, выполняющая временный сценарий, или как выражение AutoLISP, чтобы загружать и выполнить программу AutoLISP. Новый документ будет блокирован согласно уровню блокировок новой команды как определено в течение его регистрации.

Если входная подсказка в начальных взглядах команды тот же самый как первая подсказка во вторичной команде, пользователь нуждается не, знают, что две отдельных команды имеют место.

ОБРАТИТЕ ВНИМАНИЕ, поскольку эта методика вовлекает запрос от documentActivated () метод, Вы должны передать kFalse в bActivate параметр, чтобы избежать ошибок или бесконечных циклов.

Также, чтобы управлять потоком контроля поперек документов, этот повторный вызов должен поддержать любой переход, заявляют прикладные потребности. Например, неповторно используемый вариант мог помнить оригинал документа, и флажок для каждого документа, чтобы указать, является ли это уже активным, и поэтому не должны вызвать sendStringToExecute ().

Когда команда много-документа заканчивает, приложение управления должно убедиться, что команда не оставила никакие ждущие обработки состояния команды в предыдущих документах. Приложение может делать это, посылая ESC или ВВОДИТЬ в документы, которые это пересекло через, используя bWrapUpInactiveDoc параметр sendStringToExecute (). Если это не сделано, документы могут быть оставлены в не-статическом состоянии.

Координация между начальной командой и вторичной командой (и возможно множественные обращения этого) должна управляться через статический или переменные резидента динамическая.

И начальные и вторичные команды должны быть зарегистрированы через acedRegCmds () или acedDefun (). Начальная команда должна быть закодирована, чтобы закончить успешно на ее собственный, в случае, если пользователь решает исполнять полную команду без того, чтобы переключить документы. Вторая команда не должна быть полная команда, только часть команды, которая может быть вызвана, чтобы накопить информацию (внедренный в статической структуре) из различных открытых документов, и применять результатов. Вторую команду, вероятно, также придется закодировать такой, что это может быть повторно введено во все же другом документе, если именно так команда, как предполагается, будет структурирована.

Помните ту ОТМЕНУ, выполняет отдельно в каждом документе при проектировании этих конструкций.

ОБРАТИТЕ ВНИМАНИЕ, что "нормальная" acedSSGet() не жизнеспособна, потому что это может запрашивать множественные времена, таким образом не возвращая любой набор выборов в продвижении. Вместо этого, acedEntSel() используется, потому что это или возвращает примитив, или RTNONE, означая пользователя действительно сделан, или RTCAN, который может быть или реальная отмена или "перемещенный в другой документ" сигнал. Установите местный "done" флажок, исполните действие, затем стойте в очереди ESC к каждому другому активному документу так, чтобы команда была закончена в том документе следующий раз, пользователь идет к щелчку в это.

Отключение переключения документа

Команды, которые имеют длинные процессы вычисления и опрос для cancelation, восприимчивы к наличию событий пользователя, или внешние запросы ActiveX входят и вызывают проблемы с их внутренним состоянием, если они изменяют{*заменяют*} документы.

Поэтому, некоторые команды отключат переключение документа в течение их стадии обработки. Имеется список команд, включенных В AutoCAD или снабженный связанными ObjectARX-приложениями, которые отключают переключение документа при обработке:

§  PLOT

§  REGEN

§  RENDER

§  HIDE

§  SHADE

Следующие команды отключают переключение документа повсюду их обращения:

§  NEW

§  OPEN

§  TABLET

Кроме того, AcApDocManager::disableDocumentActivation() и AcApDocManager::enableDocumentActivation() отключит и будет вновь давать возможность активации документа. Прототипы для этих методов:

virtual Acad::ErrorStatus

disableDocumentActivation() = 0;

virtual Acad::ErrorStatus

enableDocumentActivation() = 0;

Следующая функция указывает, позволяется ли активация документа:

virtual bool

isDocumentActivationEnabled() = 0;

Прикладной контекст выполнения

Прикладной контекст выполнения отличен от контекста выполнения документа. Прикладной контекст выполнения обрабатывает цикл сообщения Windows.

Код, вызванный под прикладным контекстом выполнения

Приложение руководителя закодирует конструкции, которые обычно вызываются под прикладным контекстом выполнения:

§  VBA-ИНИЦИАЛИЗИРОВАЛ запросы ActiveX (осуществленный в ObjectARX).

§  ActiveX запросы, сделанные от внешних процессов, включая Visual Basic.

§  диалоговые окна Modeless, зарегистрированные ObjectARX-приложениями, или любым DLL, загруженным в соответствии с AutoCAD.

§  Все службы ObjectARX вызывает сделанным от прикладного контекста, включая любые ObjectARX-определенные окна вызова разделов, которые могут быть вызваны от них, включая заказной объект и примитив виртуальные члены, AcDb *, AcRx* реакторные члены, и AcEditorReactor члены относительно объектов базы данных.

Различия кода под прикладным контекстом выполнения

Имеется множество различий между кодом, выполняющимся в прикладном контексте выполнения и коде в других контекстах. Различия описаны ниже:

§  Это - не часть состояния командного процессора любого определенного документа.

§  Это может активизировать различные документы без немедленно приостановки, хотя это должно закончить и возвращаться прежде, чем новый активный документ может обрабатывать его ввод.

§  переключение Документа заблокирован при запросе ввода пользователя, или через ActiveX или ObjectARX запросы ввода пользователя.

§  AutoLISP также заблокирован при запросе ввода пользователя в этом контексте.

§  В случаях немодальных диалогов и внешних сгенерированных процессом запросов ActiveX, код должен блокировать документы, включая текущий документ. Использование IACADDOCUMENT методов StartUndoMarker() и EndUndoMarker() применит kWriteLock к документу.

§  средство команды не может использоваться от прикладного контекста выполнения, определенно acedCommand() и acedCmd() функции.

§  AcApDocManager::sendStringToExecute() и AcApDocManager::activateDocument() методы изменяют активный документ, но не приостанавливают выполнение кода, выполняющегося под прикладной контекст. Они приостановят выполнение кода, выполняющегося в контексте выполнения документа. AcApDocManager::sendStringToExecute() метод будет всегда очередь строка когда вызвано от прикладного контекста, при вызове, это от контекста документа будет или очередь строка, если активизирующийся параметр - kFalse, или немедленно приостанавливать контекст документа, если активизирующийся параметр - kTrue.

Другие соображения по прикладному контексту выполнения

Имеются также некоторые возможности и ограничения, которые применяются к коду, выполняющему в прикладном контексте выполнения.

§  когда контекст выполнения ваш код выполняется под, не неявен в вашей структуре кода, Вы можете делать этот запрос, чтобы найти, является ли это прикладной контекст выполнения:

Adesk::Boolean

AcApDocManager::isApplicationContext() const;

§  Все ActiveX члены ввода пользователя может использоваться, но удостовериться, что Вы вызываете их на сервисный объект, связанный с активным и текущим документом. Как отмечено выше, переключение документа будет заблокировано, когда ввод пользователя получен в этом контексте. Вы можете получить IACADDOCUMENT* образец, который соответствует потоку AcApDocument через запрос: