Связь между объектами чертежа. Есть ли какие-нибудь инструменты?

[Андрей Бушман]

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

ха-ха три раза.

хотим чтобы работало стабильно и без сбоев

В ту же корзину.

P.S. Не забывай - это же AutoCAD... "Стабильность и без сбоев" нам может только сниться. Это тебе не реляционная база данных.

P.S.2 "что бы" и "на столько" пишутся слитно (глаза режет).

[Алексей (IdeaSoft)]

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

[Алексей (IdeaSoft)]

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

[Андрей Бушман]

я сделал замечание с учётом контекста.

[Александр Ривилис]

Однако! Это я по поводу грамматических изысканий и (!!!) насмешек над стабильностью AutoCAD. Первый вопрос давайте обсуждать где-нибудь здесь: http://adn-cis.org/forum/index.php?board=23.0
Ну а второе вообще не подлежит обсуждению! Обсуждать можно конкретные баги.

[Дмитрий Загорулькин]

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

Меня интересовали не пути решения этой задачи, а есть ли стандартный инструмент в API для этого.
Конечно, использовать для хранения связи можно хоть РД, хоть ExtensionDictionary, хоть NOD, хоть любое другое место уже вне чертежа или комбинацию этих вариантов. Но у каждого из них есть недостатки, которые нужно будет чем-то прикрывать, подстраховываться и перестраховываться от различных ситуаций. Все ситуации заранее очень сложно предусмотреть, всегда есть риск упустить что-то важное.
Честно говоря, я уже не помню, зачем мне нужно было объекты связывать. Но, оценив объем работы, который придется проделать, я пошел по другому пути, без такой связи. В итоге меня это полностью устроило.

[Дмитрий Загорулькин]

И снова приходится возвращаться к этому вопросу. Причем, задача из разряда "классических":
Есть какая-то деталь. Данные о детали находятся в базе данных. На чертеже деталь отображается в виде блока (INSERT), в РД которого есть ссылка на ID записи в базе данных.
К этой детали ставится выноска. В выноске нужно отобразить информацию, которая вычисляются на основе данных о детали из базы и других данных чертежа (к примеру - порядковый номер детали в ведомости деталей). Выноска - это объект "мультивыноска"(MLEADER). Актуализация информации выполняется запуском отдельной команды.
Я придумал три варианта решения этой задачи:
1. В РД выноски помещается ссылка на ID записи о детали в базе данных.
Из плюсов такого подхода - если пользователь аккуратно пользуется стандартными инструментами редактирования (например, копирует блоки вместе с выносками), то такая "связь" не нарушается.
Из минусов - если редактировать чертеж неаккуратно, то выноски могут указывать на пустое место или вообще на другой объект чертежа, т.к. они никак не связаны с блоком, на который должны указывать. Это может привести к ошибкам на чертеже.
2. Разработать свою связь между объектами блока и выноски (как вариант - на основе тех идей, что высказывались ранее в этой теме).
Из плюсов - Если предусмотреть все варианты развития событий, то возможность возникновения ошибки на чертеже будет сведена к минимуму.
Из минусов - нужно проработать большое количество возможных ситуаций при различных действиях пользователей и есть риск, что все равно что-то останется неучтенным. И самый большой минус - при отсутствии подгруженного приложения, редактировать чертеж категорически нельзя! Иначе связи могут быть потеряны.
3. Вычислять геометрически взаимное расположение блоков и выносок и на основе этих данных делать заключение о связи между ними.
Из плюсов - никаких ограничений по использованию стандартных инструментов автокада.
Из минусов - сложно придумать алгоритм, гарантирующий на 100%, что будет установлено какая выноска на какой блок указывает. На насыщенных схемах (где одна деталь устанавливается поверх другой) есть риск, что связь будет определена неверно и появятся ошибки на чертеже.
Прошу оценить эти варианты с вашей точки зрения. Чему бы вы отдали предпочтение? Может будут еще варианты, которые я упустил?

[German]

Может будут еще варианты, которые я упустил?

Дмитрий, может вариант сломать систему блок - мультивыноска подойдет? А вариант в Civil: COGO с РД - метка?

[Дмитрий Загорулькин]

Спасибо! Вариант, как минимум, оригинальный! Но я не сторонник извращений Интуиция подсказывает, что это плохой путь.
Как показывает практика, при попытке нестандартного использования объектов, рано или поздно обязательно уткнешься в какое-нибудь серьезное ограничение, которое поставит крест на всей идее.
На мой взгляд, точки COGO хорошо использовать для сосредоточенных одиночных объектов - собственно, для чего они и создавались. В моем же случае, детали взаимодействуют между собой, имеют точки соприкосновения друг с другом, различные динамические параметры для изменения своего вида, динамический параметр для выравнивания деталей относительно друг друга... Точки COGO как минимум не покроют весь доступный функционал блоков.
 

[Дима_]

ИХМО тут два "стабильных" варианта, в зависимости от задачи и типа оформления, либо выноску поместить непосредственно в блок, либо просто програмно писать в нее "фиксированнный" текст - то есть делать "одноразовую" выноску со значениями на момент создания и не парится с дальнейшей синхронизацией с БД.

[Дмитрий Загорулькин]

Дима_, спасибо за мнение!
В блок - тогда это не выноска уже будет, а атрибут с дополнительными объектами. Придется добавить ряд динамических свойств, чтобы поведение хоть как-то приблизить к поведению выноски. И это нужно будет делать в каждом блоке деталей  А еще, получится так, что один элемент - одна выноска, а бывает же, что можно одной выноской несколько элементов обозначить. В общем, таким образом мы потеряем кучу возможностей сразу и поимеем редкостную головную боль . Но на крайний случай буду иметь в виду этот вариант. Спасибо!
Фиксированный текст без обновления - вообще не вариант. Смысл автоматизации теряется. Одно из основных пожеланий - при добавлении из базы нового типа элемента в чертеж, нужно обновить ведомость и изменить в соответствии с новой нумерацией все выноски. Новая деталь может по иерархии расположиться в середине ведомости, или вообще в самом начале, а нумерация деталей в ней сквозная. Меня не поймут, если я предложу по новой проставлять/перебивать выноски

[Дима_]

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

[Дима_]

Чего-то я забыл (а то пишу предыдущий пост и не пойму - где я это уже видел) - у меня-же есть подобное решение в одном проекте на лиспе. Для автоматической простоновки выносок в установленный аттрибут с определенным префиксом (у меня был JOIN_xxx) "видимый в текущей видимости" (у меня были дин. блоки и соответственно разные виды имели подключения в разных точках), где ххх название типа подключения (JOIN_электричество, JOIN_гидравлика и.т.д.), суть лиспа (точнее конкретной его части) - юзер выделят блоки, лисп сканирует на видимые (то есть они НЕ видимые, но лежащие в текущей видимости) на данный момент аттрибуты JOIN_... и группируя их по типам выводит "выборку" (строка запроса - та часть которая ...), после чего анализируя "кучку" параметров создает необходимые выноски (все они приходят в одну точку с единой полкой - просто стрелки от полки могут разбегаться и указывать на "свои" блоки). "Обновление" соответственно работает по точке аттрибута на который указывает выноска.
з.ы. если нужны будут подробности - пиши в личку там распишу, в общий доступ выкладывать не смогу.

[Дмитрий Загорулькин]

Ой не... лучше уж тогда атрибут-выноску!
Таких меток придется добавлять не одну. Т.к. блоки имеют сложную конфигурацию и в зависимости от свободного места метка может быть с разных сторон. Очень не хочется ограничивать точки привязки выноски - лучше, чтобы проектировщик имел свободу для творчества в этом плане.
Блоки у меня динамические, поэтому метки нужно интегрировать в эту динамику, а потом программно вычислять у каждого вхождения где эта метка находится с учетом состояния динамических параметров.
К тому же, идея такая, что пользователи будут сами создавать блоки для своих деталей, без моего участия...
Как вариант - пойдет, но мне не очень нравится...
Сейчас провожу испытания решений варианта, предложенного Андреем, с учетом замечаний Александра Наумовича. Да, придется попотеть + требовать постоянно загруженного приложения. Но в дальнейшей перспективе, мне видится, что это оправдает себя. По сути, в предложенную Андреем схему достаточно добавить реакции с DeepClone. На первый взгляд - все реализуемо.

[Дима_]

К тому же, идея такая, что пользователи будут сами создавать блоки для своих деталей, без моего участия...

Я как раз-расписывал "спецуху" как создавать такие аттрибуты (и не только их, там мануал на создание блоков на 3 страницы был).

лучше, чтобы проектировщик имел свободу для творчества в этом плане.

ИХМО наоборот "красивей" получается, когда все стрелочки в одинаковое место указывают.

Да, придется попотеть

- как сделаешь - напиши мне тоже интересно...