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

Была тема Реакторы, связывание объектов, но она была об одном из возможных способов. И результат был, по-моему, отрицательный - реакторы в AutoCAD лучше не использовать.
Т.е. вопрос остался - чем, как определять связи объектов?

Например - надписи в чертежах/моделях. Исхожу из того, что надписи всегда являются производными, вторичными, вспомогательно-иллюстративными объектами. Что надписи всегда логически связаны с объектами. Но эти связи обеспечиваются только в головах пользователей. Но не обеспечены физически.
Лучше, но не полностью обеспечены связи размеров, штриховок с объектами. Размеры и штриховки могут существовать без физических связей с объектами.

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

Обеспечение таких связей я условно разделяю на:
- определение связей, т.е. фиксацию каким-либо образом факта связи объектов,
- реализацию (актуализацию или др.) связей, т.е. средства для соответствующих действий - синхронного перемещения, поворота, наложения и пр.

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

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

[kp+]

Сообщение от АлексЮстасу Куда, как записать, обозначить, что эта надпись (или др.) связана с тем-то отрезком, сплайном и т.д.?

Так много абстракции, так мало конкретного. Пример dwg приложить бы: есть то и это, надо так и сяк.
Если надпись должна отображать стандартное свойство объекта (например, длину или площадь), то пользуйтесь полями. Я, например, считаю, что штатный интерфейс полей слишком неудобный для частого применения, в связи с чем даже сделал небольшую прогу для "механизации" этого нудного дела.
Т.е. выбираешь объект, потом надпись (текст, мтекст или атрибут), и в нее вставляется уже настроенное поле, отображающее длину объекта.

Чтобы обеспечить перемещение надписи вместе с с объектом - есть параметризация, хоть ее многие не любят.

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

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

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

Сообщение от АлексЮстасу реализацию (актуализацию или др.) связей, т.е. средства для соответствующих действий - синхронного перемещения, поворота, наложения и пр.

Примерно то же самое - реакторы (на лиспе) / события (на NET). В последнем не уверен, еще толком не реализовывал.

[Сергей812]

Сообщение от АлексЮстасу средства для соответствующих действий - синхронного перемещения, поворота, наложения и пр.

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

[zamtmn]

Кроме создания "связей" необходимы средства для навигации по ним, иначе туши свет

[Сергей812]

причем они то должны быть синхронны - создал связь, сразу в палитре отразилась и выделилась где-то в контроле списка/дерева созданная связь. И сразу можно задать дополнительные параметры на той же палитре. Но с фантазиями ТС об универсальном решении... Хотя в том же WPF можно извратиться с произвольным набором полей ввода стандартными средствами ЯП - вопрос только, нафига)

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

Сообщение от kp+ Если надпись должна отображать...

Если говорить именно о надписях, то я сам только вчера доформулировал их особенности в черчении - Начнем с начала (о надписях).

Сообщение от kp+ Так много абстракции, так мало конкретного.

Исхожу из гипотезы, что определение самого факта связи не зависит от конкретики. Например, как предлагает Кулик Алексей:

Сообщение от Кулик Алексей aka kpblc В словарь или РД (что, с моей точки зрения, более опасно) - засунуть указатель на "источник", внутрь источник по аналогии - указатели на "подчиненных".

Со словарями в лисп нужно быть супер-программистом или средние дилетанты могут разобраться?

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

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

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

Мне сильно сложным не показалось. Одно "но" - записи в словарях не модифицируются (по крайней мере под лиспом), их надо сначала сносить, потом создавать новые.

[Сергей812]

только лисп и френдли-интерфейс для работы с большим объемом разрозненных данных...

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

Сообщение от Сергей812 только лисп и френдли-интерфейс для работы с большим объемом разрозненных данных...

Не лей мне чай на спину...

[Сергей812]

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

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

Вот тут не скажи, иногда подобные "связи" засовывать во внешнюю БД нет никакого смысла.

[Сергей812]

ну если ТС, не зная программирования, решил - что он реализует (причем на лиспе) связь "динамических" параметров примитивов внутри *.dwg лучше непосредственных разработчиков - ну флаг ему в руки. Создание связей между объектами, как, например, в нашем spds graphics - вполне востребованная задача, имхо. Осталось найти волонтеров-программёров)

[trir]

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

А можно в Map 3d просто подключится к внешней БД

[zamtmn]

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

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

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

Сообщение от Кулик Алексей aka kpblc засунуть указатель на "источник", внутрь источник по аналогии - указатели на "подчиненных"

Уточни, плз, какого рода указатели имеешь в виду?

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

ename-указатели (в крайнем случае ObjectId). Насколько я помню, это допускается. Подробности были на adn-cis.org
Правда, опять же проблемы при клонировании объектов (что внутри чертежа, что между чертежами).
Offtop: Кстати, на adn-cis последнее время плохо работает (или вообще не работает) сертификат. Делайте выводы.

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

Сообщение от Кулик Алексей aka kpblc ename-указатели (в крайнем случае ObjectId). Насколько я помню, это допускается. Подробности были на adn-cis.org Правда, опять же проблемы при клонировании объектов (что внутри чертежа, что между чертежами).

Гм... А не шило ли на мыло, если что так, что эдак? Или хэндлы однозначно хуже?

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

В моей сегодняшней реальности - хендлы хуже. Доказывать не буду.

[nickname2019]

реакторы в AutoCAD лучше не использовать.

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

Сообщение от zamtmn Кроме создания "связей" необходимы средства для навигации по ним, иначе туши свет

Согласен полностью. Без средства отладки (как будут работать подобные связи) ничего более-менее сложного создать невозможно.

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

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

Интересно! Это может быть удачным компромиссом. На лиспе это делается?