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

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

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

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

Можно. Могут. https://autolisp.ru/?s=%D1%80%D0%B5%...82%D0%BE%D1%80 - это если на лиспе пишешь.

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

Сообщение от Кулик Алексей aka kpblc Можно. Могут. https://autolisp.ru/?s=%D1%80%D0%B5%...82%D0%BE%D1%80 - это если на лиспе пишешь.

Есть в тексте из ссылки:

Параметрические зависимости ... реализованы через объектные реакторы: т.е. на каждый "завязанный" в параметрические зависимости графический примитив дополнительно вешается отдельный объектный реактор.

В параметрических зависимостях именно те реакторы, что в лиспе? Или в них другие инструменты?

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

Насколько я понимаю, они реализованы не на лиспе, но основываются примерно на тех же механизмах.

[Сергей812]

Сообщение от Кулик Алексей aka kpblc но основываются примерно на тех же механизмах.

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

[zenon]

Сообщение от Сергей812 "Ядро" акада в какие то стабильные для состояния самого акада моменты времени вызывает очереди подключенных обработчиков событий (реакторов) для возможности реакций внешних надстроек.

Во загнул!
PS пять раз прочел прежде чем понял о чем речь.

[Boxa]

ИМХО, то, что Вы не часто встречаете "реакторы" это нормально, однако это не означает, что их мало используют.
Будет ли тормозить и вызывать проблемы, зависит от реализации...

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

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

Если параметризация сделана принципиально теми же средствами, что и реакторы лисп, то, вероятно, с реакторами будет то же - сильное торможение AutoCAD.

Хорошо бы понять степень этого "примерно" - критично или нет.

Сообщение от Boxa ИМХО, то, что Вы не часто встречаете "реакторы" это нормально, однако это не означает, что их мало используют.

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

Сообщение от Boxa Будет ли тормозить и вызывать проблемы, зависит от реализации...

Т.е. Вы считаете, что реакторами реально?

[Сергей812]

Сообщение от АлексЮстасу Т.е. Вы считаете, что реакторами реально?

на лиспе для тысяч объектов - ну если вы не Мак Ли, то лучше и не беритесь)

На .Net/ARX можно рискнуть, при этом:
1. Не полагайтесь на последовательность вызова обработчиков событий в строгой соответствии с проводимыми операциями. События обязательно будут, но не обязательно в то время и в том порядке - который ожидаете в результате выполнения своего кода.
2. Внутри событий не стоит использовать интерактивные функции и диалоговые окна. Рискуете в лучшем случае получить ошибку, в худшем - непредсказуемый результат.
3. Строго следить за обеспечением невозможности рекурсивного выполнения цепочки обработчиков событий. Т.е. если обработчик события А "дергает" через действия с тем же документом обработчик события Б, а обработчик события Б вызывает своими действиями обработчик события А - все, здравствуй рекурсия и краш.

Т.е. код придется оптимизировать и тестировать очень тщательно. Что накладывает определенные требования к уровню самого разработчика надстройки)

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

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

Тогда - ИМХО!- лучше делать отдельной командой / функцией, которая будет вызываться либо по требованию пользователя, либо (к примеру) по событию сохранения документа. Правда, там понадобятся другие знания и другие подходы

[Сергей812]

Сообщение от Кулик Алексей aka kpblc Тогда - ИМХО!- лучше делать отдельной командой / функцией, которая будет вызываться либо по требованию пользователя, либо (к примеру) по событию сохранения документа.

либо в обработчике idle, либо changedstatelockdocument.

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

Ну это уже не в лиспе - там про такое лично я даже не слышал

[Сергей812]

Сообщение от Кулик Алексей aka kpblc Ну это уже не в лиспе

idle вроде нет реактора, а изменение состояния блокировки документа - vlr-documentLockModeChanged.

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

Я в своей практике ограничивался реакторами на команды и изменения системных переменных. Остальное прошло как-то мимо: наверное, просто было не надо.

[Сергей812]

ну это специфические вещи - например

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

Сообщение от Сергей812 На .Net/ARX можно рискнуть...

Через 15 или сколько там лет все еще рискнуть...

Сообщение от Кулик Алексей aka kpblc Тогда - ИМХО!- лучше делать отдельной командой / функцией, которая будет вызываться либо по требованию пользователя, либо (к примеру) по событию сохранения документа.

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

Сообщение от Кулик Алексей aka kpblc Правда, там понадобятся другие знания и другие подходы

Другие - есть еще альтернативы динамике, параметризации, реакторам?

[Сергей812]

Сообщение от АлексЮстасу Через 15 или сколько там лет все еще рискнуть

если бы подобное реализовывалось без проблем - уже давно была бы информация об этом. Но попробовать можно)

Сообщение от АлексЮстасу Другие - есть еще альтернативы динамике, параметризации, реакторам?

чтобы с гарантированным результатом - никаких. А так можно еще свои примитивы на ObjectARX делать, например.

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

Сообщение от АлексЮстасу Другие - есть еще альтернативы динамике, параметризации, реакторам?

Ну да. Где и как хранить, откуда и как доставать нужные данные - вопрос уже к разработчику (спойлер: РД для этого вряд ли подойдут). Ну и что делать с полученными данными - тоже прерогатива разраба.

[Сергей812]

Сообщение от АлексЮстасу логическую связь объектов - какие-то блоки должны быть на вершинах полилиний

1. У блока на вершине полилинии должна быть точка вставки, геометрический центр или что-то еще?
2. Нужно как-то запомнить, к какой именно вершине и какой полилинии пристыкован данный блок. А так же запомнить координаты этой вершины.
3. В обработчике события модификации примитива проверять - не было ли изменения данной полилинии, и не было ли изменение координат опорной (для блока) вершины. Если были - занести в очередь команду перемещения блока вслед за "ушедшей" полилинией.
4. Например, в обработчике событии простоя перенести блок и очистить очередь команд.
И это только на одну связь. А если связей много, и среди них есть зависимые - придется очередь команд еще анализировать на первоочередность выполнения. И что бы все это занимало менее 100-200мс, иначе будут слишком заметны тормоза интерфейса. Т.е. данные придется буферизировать, при этом следя за их актуализацией. И пойдет цепляться одно за другое...

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

Перед созданием темы смог вспомнить только одну известную лисп-программку, где, предполагал, что использовались реакторы для объектов - Align Text, MText or Attribute to Curve от помянутого выше Lee Mac. 2009-2010 гг.
Посмотрел результаты - к линиям он присоединяет XData с handle и пр.

Опять отсюда:

Параметрические зависимости ... реализованы через объектные реакторы: т.е. на каждый "завязанный" в параметрические зависимости графический примитив дополнительно вешается отдельный объектный реактор.

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

[Сергей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

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