[АлексЮстасу]

Постоянно, бесконечно вручную обеспечиваем логическую связь объектов - какие-то блоки должны быть на вершинах полилиний, какие-то отрезки перпендикулярны, надписи параллельны линиям и т.д., и т.п.
Редактирование одного может приводить к нарушениям во многом.
Динамическими блоками все не сделать, параметризация сильно тормозит, программок на каждый набор объектов не напасешься.

Мне встречалось у программистов упоминание реакторов. Но очень редко. И на практике, среди множества программ, за все годы не попадалось. (Что настораживает ).
Можно ли в принципе сделать аналог параметризации через реакторы: сохранение параллельности или перпендикулярности, или примыкания и т.д., и пр.?
Или при их массовом применении реакторы так же будут тормозить AutoCAD, как параметризация? Создавать другие проблемы?

[Сергей812]

Сообщение от АлексЮстасу Может быть стоило бы не на каждый примитив вешать реактор, а сделать "внешние" реакторы на каждый тип события? У объектов сохранять сведения о типах реакции, а при соответствующем событии обрабатывать сразу все [все указанные или один изменяемый] объекты с нужным типом реакции?

ну об этом примерно выше и написал. Собирается информация в очередь команд программной надстройки по событиям изменения БД чертежа, и затем "пакетно" модифицируются зависимые примитивы.

[АлексЮстасу]

Сообщение от Сергей812 ну об этом примерно выше и написал. Собирается информация в очередь команд программной надстройки по событиям изменения БД чертежа, и затем "пакетно" модифицируются зависимые примитивы.

Можно же не пакетно для всех, а для одних только что измененных объектов?

[trir]

Это всё решается штатными методами Map 3D

[Кулик Алексей aka kpblc]

Сообщение от АлексЮстасу Посмотрел результаты - к линиям он присоединяет XData с handle и пр.

... и при копировании объектов между чертежами ты (ориентируясь только на хэндлы) можешь получить очень неожиданные результаты

[Сергей812]

Сообщение от АлексЮстасу Можно же не пакетно для всех, а для одних только что измененных объектов?

так в очереди и будут только команды на объекты, зависимые от измененных примитивов. Так как информация заносится по событиям модификации БД чертежа. А еще пользователь может отмену изменений произвести - это тоже надо обрабатывать. И чтобы не организовалось взаимных зависимостей между примитивами - пользователь это явно не будет отслеживать. В общем, дофига)

----- добавлено через ~9 мин. -----

Сообщение от Кулик Алексей aka kpblc и при копировании объектов между чертежами ты (ориентируясь только на хэндлы) можешь получить очень неожиданные результаты

сохранить в XData хэндл самого примитива, и потом пересинхронизировать связи при необходимости.

[Кулик Алексей aka kpblc]

Сообщение от Сергей812 сохранить в XData хэндл самого примитива, и потом пересинхронизировать связи при необходимости.

Если использовать только лисп, задача становится не сильно тривиальной ИМХО.

[АлексЮстасу]

Сообщение от Кулик Алексей aka kpblc ... и при копировании объектов между чертежами ты (ориентируясь только на хэндлы) можешь получить очень неожиданные результаты

Во-первых, не я - он.
Во-вторых, если в XData хендл записан в поле типа 1005, то он при копировании в др. чертеж поменяется на действительный.
Но сейчас речь не об XData - ты первый начал.

Да, кстати, что, кроме (или вместо) handle нужно сохранять? Что еще, надежнее-однозначнее-полнее, идентифицирует графэлемент?

Пока гипотеза:
1. сохранять для "базового" объекта сведения о типах реакций [и о связанных объектах: связь1 - список связанных, связь2 - список связанных и т.д.]
2. для связанных объектов сохранять сведения о деталях связи: "базовый" объект, нужное действие, координаты, углы, номера вершин и пр.
3. при событии модификации (любой) объекта производить со связанными объектами соответствующие действия из 2.

Т.о, реакторов AutoCAD может быть достаточно только одного - на модификацию объектов. Действия же можно реализовать доппрограммами. Наверное, это не даст таких тормозов, как при реакторах в объектах, и не создаст др. сложностей от их использования.

Если выбор по handle или т.п. требует перебора всего, то списки связанных не нужны. (Я не программист - не знаю, как технически выбираются объекты по handle или т.п.)

Сообщение от Сергей812 так в очереди и будут только команды на объекты, зависимые от измененных примитивов.

Да, все зависимые от только что измененных. Но не вообще для всех объектов со связями. Так явно упростится-ускорится процесс.

Сообщение от Сергей812 А еще пользователь может отмену изменений произвести - это тоже надо обрабатывать.

Разве есть проблемы с отменой?

Сообщение от Сергей812 И чтобы не организовалось взаимных зависимостей между примитивами - пользователь это явно не будет отслеживать.

В смысле? Как они вдруг сами организуются?

----- добавлено через ~10 мин. -----

Сообщение от trir Это всё решается штатными методами Map 3D

Во-первых, я не соображу, как обеспечить связь, допустим, масок с контурами или блоков с линиями средствами Map3D.
Допустим, "топологии" некоторые связи устанавливают, да только после модификаций графэлементов рушатся.

Но здесь-сейчас принципиально я хотел бы рассматривать только средства базового AutoCAD.

[Сергей812]

Сообщение от Кулик Алексей aka kpblc Если использовать только лисп, задача становится не сильно тривиальной ИМХО.

если использовать только лисп - вопрос в заторможенности интерфейса на реальных чертежах со всеми навесками обработчиков реакторов)

Сообщение от АлексЮстасу Во-вторых, если в XData хендл записан в поле типа 1005, то он при копировании в др. чертеж поменяется на действительный.

Ну поменялся автоматически хэндл на другой - а как другой элемент узнает, на какой примитив у него теперь ссылка? А если сохранить хэндл примитива в виде строки/числа, и текущее значение хэндла примитива отличается от записанного - это признак необходимости вызова метода синхронизации ссылок.

Сообщение от АлексЮстасу Разве есть проблемы с отменой?

просто тоже надо обрабатывать события)

Сообщение от АлексЮстасу В смысле? Как они вдруг сами организуются?

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

[АлексЮстасу]

Сообщение от Кулик Алексей aka kpblc ориентируясь только на хэндлы

Как эту проблему копирования решить, что сохранять вместо/вместе с handle?

Сообщение от Сергей812 просто тоже надо обрабатывать события)

Событие отмены нельзя исключить? С другой стороны - ну, отработать, в чем проблема?

Сообщение от Сергей812 если не проверять при указании пользователем зависимостей наличие рекурсивных ссылок между примитивами - легко)

Легко что? При обработке событий произвести их последовательно - на скорости не скажется, а результат на совести наворотившего ерунды пользователя.

[Кулик Алексей aka kpblc]

Сообщение от АлексЮстасу Как эту проблему копирования решить, что сохранять вместо/вместе с handle?

Подозреваю, что надо указывать не хендлы, а указатели на связанные примитивы. Но что будет при копипасте что внутри чертежа, что между файлам - я хз,

[Сергей812]

Связь между объектами чертежа

[АлексЮстасу]

Сообщение от Кулик Алексей aka kpblc Подозреваю, что надо указывать не хендлы, а указатели на связанные примитивы. Но что будет при копипасте что внутри чертежа, что между файлам - я хз,

Т.е. с этими указателями при копипастах может быть то же, что с хендлами? Гм...

[Сергей812]

по последней ссылке верхушка айсберга того, куда хотите влезть.. Но, похоже, реакторы тоже будут рассматриваться "созерцательно", как XData в свое время)

[trir]

или блоков с линиями средствами Map3D

аннотации

[Сергей812]

Так, для понимания масштабов задачи - одни только события:

Application Events

DocumentCollection Events

Document Events

Database Events

Editor Events

и сколько из них придется задействовать - покажет только прогон надстройки на реальных задачах и пользователях.