§ Всегда проверяют текущее значение SDI перед созданием изменений. Если текущее значение - 2 или 3, не измените это.
§ Изменяющий SDI к 1 от 0 будет терпеть неудачу, когда AutoCAD имеет больше чем один открытый документ.
Вся проверка блокировки документа заблокирована, когда AutoCAD выполняется в любом из режимов SDI.
ОБРАТИТЕ ВНИМАНИЕ На этот режим совместимости, и SDI переменная будет удалена в следующем полном выпуске AutoCAD.
Уровни Совместимости
Ваше ObjectARX-приложение может иметь один из четырех уровней совместимости с MDI:
§ SDI-ТОЛЬКО
§ MDI-ЗНАЮЩИЙ
§ MDI-СПОСОБНЫЙ
§ MDI-РАСШИРЕННЫЙ
SDI-ТОЛЬКО - минимальное требование, но MDI-СПОСОБНАЯ совместимость рекомендуется.
MDI поддерживает контекст выполнения в документ и обеспечивает средство для разрешения единственного контекста выполнения, чтобы быть активным при переключении документов.
SDI-ТОЛЬКО Уровень
Это - основной уровень совместимости и не достаточно для наиболее устойчивых приложений. Этот уровень не будет позволять вашему приложению работать под MDI, но это должно работать без того, чтобы терпеть неудачу под SDI.
Создавать приложение SDI-Only
1 Регистрируют ваше приложение как SDI-ТОЛЬКО, вызывая AcRxDynamicLinker::registerAppNotMDIAware () в kInitAppMsg обработчике acrxEntryPoint ().
2 Гарантируют, что ваше приложение может брать AcRx:: kUnloadAppMsg немедленно после возвращения от обработки AcRx:: kInitAppMsg. Это произойдет, если ваше приложение не регистрируется как являющийся MDI-ЗНАЮЩИЙ, и AutoCAD уже имеет открытые множественные документы.
MDI-ЗНАЯ Уровень
Этот уровень совместимости обеспечивает минимальные требования для ObjectARX-приложения, чтобы функционировать в среде MDI без неудачи.
ObjectARX-приложение должно встретить{*выполнить*} требования этого уровня совместимости перед способностью законно установить SDI переменную системы в 0.
Следующий список суммирует минимальные требования.
N Приложения не может сохранять данные " в документ " в глобальных или статических переменных.
N, если команда выполнена от прикладного контекста, это должно обеспечить явный документ блокировка.
N Автошепелявящиеся - зарегистрированные команды должен быть подготовлен, чтобы действовать в пределах множественных государств AutoLISP.
N Приложения должен регистрировать себя как MDI-ЗНАЮЩИЕ в течение их AcRx:: kInitAppMsg обработчик в acrxEntryPoint ().
Каждое требование описано подробно в следующих секциях.
Данные " в документ "
Приложения не могут сохранять данные " в документ " в глобальных или статических переменных.
Это включает объекты AcDbDatabase, объекты AcDbObject, AcDbObjectId значения, значения переменной заголовка, значения переменной документа, наборы выбора, и другая документированная - определенная информация. Любое возникновение данных " в документ " в глобальных и статических переменных могло бы быть разрушено, если ваше приложение - работают в множественных параллельных сеансах редактирования.
Чтобы избегать коррупции данных, Вы можете формировать поведение команды и данные в классы. Образец класса может инициализироваться для каждого запроса к команде. Поскольку команда приобретает документированные - определенные данные, это сохраняет ее собственные копии " в случай " этого данными.
Другое решение состоит в том, чтобы формировать все глобальные и статические данные в структуру или класс. Копия данных инициализируется для каждого документа. Местный указатель на соответствующий образец установлен в каждой точке входа в приложении. Местный указатель тогда используется, чтобы обратиться к данным " в документ ".
Используйте documentActivated () реактор, чтобы переключить между образцами скрытых данных.
Вы можете создавать данные " в документ " на как - необходимом основании, или создавать это, когда приложение сначала загружено. Если создано на как - необходимом основании, поскольку зарегистрированные команды приложения или реакторы вызваны{*названы*}, текущий документ определен, и запрос сделан, чтобы получить данные документа. Если это не найдено, это создано в то время.
Создавать данные " в документ " когда приложение сначала загружено, использование AcApDocumentIterator в AcRx:: kInitAppMsg обработчик, чтобы получить список всех открытых документов. Тогда используйте AcApDocManagerReactor:: documentCreated () чтобы знать, когда создать дополнительные данные " в документ " для документов, открыл после того, как приложение загружено.
Какой бы ни метод используется, чтобы ассигновать{*разместить*} данные " в документ ", приложение должно использовать AcApDocManagerReactor::documentToBeDestroyed () реактор, чтобы знать, когда удалить данные. Приложения должны также удалить остающиеся данные в течение AcRx:: kUnloadAppMsg обработчик.
Явная блокировка документа
Имеются два типа контекстов выполнения, приложения и документа. Все зарегистрированные команды и реакторные повторные вызовы выполнены в пределах контекста выполнения документа. Сообщения Windows и повторные вызовы, и некоторый acrxEntryPoint () сообщения выполнены в пределах прикладного контекста.
Явная блокировка требуется только в прикладном контексте выполнения. Блокировка и разблокирование автоматически обработаны для команд, выполняющихся в контексте документа.
Любые команды, которые должны работать вне активного документа, должны вручную исполнить документ блокировка использование следующих типов блокировки.
§ Доступный только для чтения
§ Исключительное чтение
§ Общедоступная запись
§ Исключительная запись
Блокировка в прикладном контексте выполнения может быть сделана, вызывая acDocManager - > lockDocument (). Следующая таблица описывает четыре уровня блокировки опций:
Типы блокировки Команды
Блокировка Команды | Режим Блокировки | Флажки Команды | Описание |
Read only | (not locked) | ACRX_CMD_DOCREADLOCK | Для доступа только для чтения к объектам, блокировка не необходима. Например, чтобы открыть AcDbObject для Acad:: kForRead, или вызывать acedGetVar (), блокировка не необходима. |
Exclusive read | AcAp::kRead | ACRX_CMD_DOCREADLOCK, ACRX_CMD_DOCEXCLUSIVELOCK | Использование исключительного режима чтения предотвращает любой другой контекст выполнения от блокировки документа для записи. Этот режим гарантирует, что документ не будет изменяться в течение блокировки. |
Shared write | AcAp::kWrite | (default) | Заданный по умолчанию режим блокировки. Множественные контексты выполнения могут держать одновременные общедоступные блокировки записи. Команда может делать изменения к документу, и когда команда приостановлена, другие команды могут делать изменения к документу. |
Exclusive write | AcAp::kXWrite | ACRX_CMD_DOCEXCLUSIVELOCK | Гарантирует, что ваш контекст выполнения имеет монопольный доступ, чтобы изменить ресурсы документа |
Команды AutoLISP
Команды AutoLISP должны знать, что имеется отдельный стек AutoLISP для каждого документа. Это означает, что переменные AutoLISP должны быть обработаны таким же образом как другая глобальная переменная " в документ " и статические данные. Для большего количества информации, см. “ Данные " в документ " ” на странице 424.
AcRx:: kLoadDwgMsg сообщение в acrxEntryPoint () послан для каждого документа, открытого, когда приложение сначала загружено, и когда любые новые документы открыты, в то время как приложение выполняется. Сообщения посланы от контекста выполнения соответствующего документа.
Регистрация как MDI-ЗНАЮЩИЙ
Приложения, которые встретили{*выполнили*} все эти критерии, должны регистрировать себя как MDI-ЗНАЮЩИЕ в их AcRx:: kInitAppMsg обработчик в acrxEntryPoint (), используя функцию acrxDynamicLinker - > registerAppAsMDIAware (). Приложения, не зарегистрированные как MDI-ЗНАЮЩИЙ не могут быть загружены, когда больше чем один документ открытые. Если такое приложение загружено, дополнительные документы не могут быть открыты.
MDI-СПОСОБНЫЙ Уровень
Достижение этого уровня согласия вовлекает создание вашей работы кода так эффективно и естественно в режиме MDI, как это делает (или делало) в режиме SDI.
§ переключение документа поддержки.
Секции Кода, включающие AcEd-зарегистрированные команды, которые вызваны непосредственно от тех конструкций, вероятно будет делать паузу для ввода пользователя, и более вероятны восприимчивы к коррупции, когда множественные сессии сделаются. Наиболее общий случай должен ввести команду в один документ, подсказка для ввода пользователя, затем переключать документы и вводить ту же самую команду в различный документ. Пока Вы поддерживаете жизненную информацию относительно основания " в открытый документ ", ваше приложение должно функционировать должным образом. Иначе, ваш код должен отключить переключение документа.
§ поддерживают хорошую работу.
Когда это становится временем, чтобы смотреть на выполнение{ работу*}, много разыменования указателя резидента динамическая к тому, что было прежде статические адреса, может трясина вниз выполнения{*работы*} программы. В этом случае, альтернатива была бы должна обслужить{*поддержать*} статический буфер памяти элементов текущего документа, который будет просмотрен в от и выписан к документированным - определенным элементам динамической памяти.
MDI-РАСШИРЕННЫЙ Уровень
Эти дополнительные шаги будут заставить ваше приложение интегрировать полностью с МНОГОДОКУМЕНТАЛЬНЫМ ИНТЕРФЕЙСОМ.
§ Рассматривают перемещение вашего AcEditorReactor:: commandXxx () и AcEditorReactor:: LispXxx () повторные вызовы, чтобы работать вместо этого от AcDocMananagerReactor::documentLockModeWillChange () и AcDocMananagerReactor::documentLockModeChanged () уведомления. Тогда они объяснят прикладные операции контекста выполнения, которые были предварительно трудны обнаружить ObjectARX-приложениями.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 |


