Прокси-объект для пользователя
Сообщение AutoCAD уведомляет пользователей относительно создания прокси-объектов. Пользователи могут читать относительно прокси-примитивов, использующих команду LIST. Они могут также сталкиваться с прокси-объектами из-за способа, которым примитивы отображены и путь, которым они отвечают на редактирование.
AutoCAD отображает сообщение немедленно после любой команды, которая заставляет прокси-объект быть созданной (например, DXFIN, XREF, ВСТАВЛЯТЬ). Сообщение включает число прокси-примитивов, созданных с визуальным представлением, число созданных прокси-примитивов, который не может быть отображен из-за отсутствия родительского приложения, и числа прокси-объектов, созданных без визуального представления.
Операция LIST, выполненная на прокси-объекте идентифицирует приложение, которое создавало заказной объект, и идентифицирует объект как являющийся или типа ACAD_PROXY_OBJECT или ACAD_PROXY_ENTITY.
Пользователи могут управлять дисплей прокси-объектов с PROXYSHOW переменной системы, которая имеет следующие опции:
1 Ни один показанный
2 Графическое представление
3 Границы поля
Отображение прокси-примитивов
AutoCAD не может отображать прокси-примитив, используя worldDraw объекта () или viewportDraw () функции, потому что родительское приложение отсутствует. Это использует информацию в графическом метафайле примитива, который содержит данные, полученные из worldDraw примитива () или saveAs () функция, когда рисунок был последний{*прошлый*} сохранен (с командой SAVE ИЛИ SAVEAS). Формат дисплея является или таковым примитива непосредственно, или поля ограничения, указывающего том{*объем*}, населенный примитивом. Формат определен установкой PROXYGRAPHICS переменной системы во время рисунка, сохранен. Формат поля ограничения
Является полезным прежде всего, чтобы минимизировать размер выходного файла, когда данные для заказных примитивов большие.
Редактирование прокси-примитивов
Степень, к которой прокси-примитивы могут быть отредактированы, определена родительским приложением. Это определение{*намерение*} сделано, когда класс создан с макрокомандой ACRX_DXF_DEFINE_MEMBERS. Параметр PROXY_FLAGS определяет типы редактирований, которые могут быть сделаны к примитиву, если это становится полномочным. Имеющие силу опции для PROXY_FLAGS, и их связанных значений, перечислены в следующем
Таблица.
Полномочные опции флажков
Опция | Значение |
KNoOperation | 0 |
KEraseAllowed | 0x1 |
KTransformAllowed | 0x2 |
KColorChangeAllowed | 0x4 |
KLayerChangeAllowed | 0x8 |
KLinetypeChangeAllowed | 0x10 |
KLinetypeScaleChangeAllowed | 0x20 |
KVisibilityChangeAllowed | 0x40 |
KAllAllowedBits | 0x7F |
Обратите внимание, что kNoOperation не означает ни один из других опций, перечисленных здесь.
Вы можете логически опции OR PROXY_FLAG, чтобы разрешать комбинацию редактирования операций.
Поскольку прокси-примитивы только формируют данные ниже уровня базовых классов AcDbEntity, любые изменения, сделанные, чтобы окрасить, уровень, linetype, linetype масштаб, и видимость будет выписан как часть данных прокси-примитива. Твердые преобразования тела (типа перемещения, масштаба, и вращаются) не может применяться, пока родительское приложение не присутствует. Когда преобразование применяется к полномочному, преобразование сделано к графическому метафайлу, и копия матрицы преобразования сохранена в заказной записи в словаре расширений полномочного примитива. Если множественные преобразования выполнены, матрица модифицирована, чтобы отразить совокупное преобразование. Когда заказной примитив возвращен памяти с его родительским приложением, AutoCAD вызывает transformBy() примитива, передает этому данные матрицы преобразования, и удаляет заказную запись хранения данных от словаря расширения. В действительности, преобразование задержано, пока родительское приложение не присутствует, чтобы применить преобразование к заказному примитиву.
Разгрузка приложения
Когда приложение разгружено, и соответствующие операции уборки были выполнены, заказные объекты, и примитивы преобразованы в прокси-объекты. Для этого, чтобы произойти, все классы пользователя должны быть удалены из ObjectARX в, разгружают время с deleteAcRxClass () функция. Для описания требований для создания приложения “ незагружаемый, ” см. главу 3, “ Основы ObjectARX-приложения. ”
Глава15. Уведомления
Эта глава описывает, как Вы можете создавать реакторы, которые отвечают на различные типы случая и регистрируют реакторы с соответствующими объектами, чтобы получить уведомление.
- Краткий обзор уведомлений Использование реакторов Руководящие принципы использования уведомлений
Краткий обзор уведомлений
Когда событие происходит в системе, некоторых объектах, вызванных{*названных*} уведомителях, автоматически передайте событие к другим объектам. Например, когда копии пользователя, стирания, или изменяют объект или когда пользователь выпускает команду UNDO ИЛИ REDO, соответствующее уведомление для каждого события автоматически вызвано.
Объекты, получающие события - вызванные{*названные*} реакторы. Реактор должен быть явно добавлен к реакторному списку уведомителя прежде, чем это может получать события от уведомителя. Данный уведомитель может иметь множество реакторов в его реакторном списке. Определение класса реактора включает различные функции уведомления. Когда событие происходит, уведомитель автоматически вызывает соответствующую функцию уведомления каждого реактора в его реакторном списке.
Использовать реактор в приложении
1 Получают новый реакторный класс и осуществляют функции уведомления для событий, ваш реактор ответит на.
2 Инициализируют реактор.
3 Добавляют реактор к реакторному списку уведомителя.
При закончено использование реактора
1 Удаляют реактор из реакторных списков всех уведомителей, к которым это было добавлено.
2 Удаляют реактор (если это не объект резидента базы).
Использование реакторов требует подклассов создания реакторных классов или классов AcDbObject. Эта глава предполагает, что Вы знакомы с материалом, представленным в главе 11, при Наследовании Заказного ObjectARX Класса, ” и главы 12, “ Происходящий от AcDbObject. ”
Реакторные Классы
Реакторные классы получены из AcRxObject, не AcDbObject. Поскольку эти реакторы - не, объекты базы данных, монопольное использование не обращаются к ним, и они не имеют объект IDs.
Различные виды реакторов получают различные типы событий уведомления. Реактор базы данных (полученный из AcDbDatabaseReactor) получает события, связанные с состоянием базы данных — например, когда объект добавлен в конец к базе данных, изменяется в базе данных, или стерт. Уведомитель реактора - база данных, так что это добавлено к реакторному списку AcDbDatabase. Реактор объекта (полученный из AcDbObjectReactor) отвечает на события на объектном уровне, типа копирования, стирания, или изменения объект. Это может быть добавлено к реакторному списку любого AcDbObject. Редактор реактор (полученный из AcEditorReactor) отвечает на AutoCAD-специфичные события типа загрузки и разгрузки рисунка, старта или окончания команда, и другие виды взаимодействия пользователя. Объект AcEditor - единственный уведомитель для AcEditorReactor.
Следующее - иерархия классов для реакторных классов:
AcRxObject
AcApDocManagerReactor
AcApLongTransactionReactor
AcDbDatabaseReactor
AcDbObjectReactor
AcDbEntityReactor
AcDbRasterImageDefFileAccessReactor
AcDbRasterImageDefTransReactor
AcEdInputContextReactor
AcRxDLinkerReactor
AcRxEventReactor
AcEditorReactor
AcTransactionReactor
Типы Объектных Реакторов
Реакторные классы, показанные выше также упомянуты как переходные реакторные классы. Если Вы хотите, чтобы ваша программа получила уведомление события, вы будете обычно использовать переходные реакторы, которые контролируют события, которые случаются с объектами базы данных. Они могут также контролировать события базы данных, взаимодействие пользователя, и другие события системы, в то время как приложение выполняется.
Другой вид реактора, названного постоянный реактор, использует объект базы данных (образец класса AcDbObject или полученного класса) как реактор. Объекты Базы данных могут получать также как посылать уведомление. Постоянные реакторные зависимости в пределах базы данных - часть базы данных, так что они сохраняются в DWG и DXF файлах и восстановлены, когда рисунок загружен.
Использовать AcDbObject как реактор
1 Получают новый AcDbObject класс и осуществляют функции уведомления для событий, ваш объект ответит на.
2 Инициализируют объектный реактор.
3 Добавляют объектный реактор к базе данных и дают этому владельца, предпочтительно контейнерный объект, так, чтобы это было зарегистрировано из правильно.
4 Добавляют объектный реактор к реакторному списку уведомителя, используя addPersistentReactor () функция. Эта функция требует, чтобы Вы прошли в объекте ID объектного реактора, который Вы создавали в шаге 2.
AutoCAD удалит объектный реактор, потому что это - объект базы данных.
ОБРАТИТЕ ВНИМАНИЕ, когда Вы копируете объект, любые постоянные реакторы, приложенные к объекту скопированы также. Переходные реакторные приложения не скопированы, когда объект скопирован.
Использование Реакторов
Чтобы использовать переходный реактор, получите новый класс из одного из следующих базовых классов:
AcRxDLinkerReactor
ObjectARX-приложение Мониторов загрузка и разгрузка.
AcEditorReactor
Контролирует AutoCAD-специфичные события типа оценок AutoLISP и Команд.
AcDbDatabaseReactor
Создание Мониторов, модификация, и стирание объектов базы данных.
AcTransactionReactor
События Мониторов, связанные с операционным менеджером — начало, аварийное прекращение работы, или конец сделки.
|
Из за большого объема этот материал размещен на нескольких страницах:
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 |


