Изменение функционала для документа типа "Технологическая сборка"

[Andy]

Здравствуйте! Мне показалось интересным обсуждение темы назначения технологической сборки.
Само предложение выглядит так:

Мне кажется, было бы полезным, чтобы в "Технологической сборке" имелся бы некий запрет на изменение входящих в неё "боевых" деталей в контексте сборки. Ну т.е. деталь имеющая некий признак "боевая" (деталь изготавливаемого "серийного" изделия) не должна получать контекстные зависимости и изменяться в режиме "редактирования на месте", т.к. ОНА есть "исходная" (читай "утвержденная") деталь и изменяться (ну, по крайней мере, в этой сборке) не должна. Вот тогда иной по отношению к "обычной" сборке тип файла имел бы смысл, т.к. обладал бы иным функционалом.

И чтоб не вырывать его из контекста обсуждения даю ссылку на топик: https://forum.ascon.ru/index.php?topic=36144.0

[Ушкуй]

Существующего функционала не хватает?

[Andy]

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

[YNA]

Вот один из вариантов применения.
Представте. что у вас в папке лежат куча Сборок и Тех-сборок. Как их отдельно выделить? На глазок трудно, да и ошибиться можно. В таком случае нажимаем кнопочку Группировать и получаем отдельные группы Сборок и Тех-сборок. Это чисто пользовательское удобство поиска и разделения. Возможно есть в этом типе документа ещё какой то потайной смысл, но для пользователя наверное мало толку.

[Andy]

На глазок трудно, да и ошибиться можно

Никогда так не делаю и Вам не советую. Я открываю спецификацию, а уж потом из неё нужный мине присоединенный документ. Вот тут точно ошибки не будет.
PS
ИХМО, Ваше сообщение к моему предложению отношения не имеет

[СВ]

 Однозначно: "технолог" не имеет права редактировать "боевые" детали. Но менять-то ему что-то/как-то нужно ...
Получается: нужно иметь связь с "боевой" НЕРЕДАКТИРУЕМОЙ деталью и одновременно иметь возможность менять её (в процессе "обработки").

[YNA]

Никогда так не делаю и Вам не советую. Я открываю спецификацию, а уж потом из неё нужный мине присоединенный документ. Вот тут точно ошибки не будет.

Спорить не буду, потому что в Спецификации мало понимаю (а точнее ни чего не понимаю). Возможно в Спецификации есть какой то навороченный поисковик, который быстро группирует файлы по типам, но мне кажется, что обычный Проводник, 7-zip, Тотал Командер и т. п. всё таки лучше для этого приспособлены.

[Andy]

Опять  "Флуд" "замыливает" основную тему.
А по поводу:

Спецификации мало понимаю (а точнее ни чего не понимаю

Как же вы тогда работаете с Компасом и что там делаете? - Это не шутка и не "стёб". Мне действительно интересно то, как в реальной жизни работают люди с системой...

[GenTAPo]

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

[IgorT]

Интересно, а прочие болячки Компаса не напрягают ТСа? В чем мотивация обсуждения темы именно про технологическую сборку?

[СВ]

 Игорь, это просто замечательно, что Андрей поднял вопрос по РЕДКО затрагиваемой теме. И судя по его подходам, в Компасе напрягает многое. В общем, он "одной с нами крови". Я так думаю.

[IgorT]

Игорь, это просто замечательно, что Андрей поднял вопрос по РЕДКО затрагиваемой теме. ...

А меня что-то не замечательно. Не понимаю.
Сам то ТС что скажет?

[СВ]

 Да что это сегодня, уже второй человек недоволен "в принципе".
Отвечу за автора (потому что ответ очевиден): - В конкретной теме пишут конкретно по теме. Как и положено для ПРЕДЛОЖЕНИЙ. Или предлагаете ЗДЕСЬ собрать ВСЁ недовольство Компасом?

[IgorT]

Могу вообще ничего не говорить.

[Andy]

Сам то ТС что скажет?

Что Вам сказать...
Используя систему Компас еще с тех времен, когда она работала под DOC, скажу, что в целом система прогрессирует по своему функционалу очень не плохо.
Естественно, что недоработки и косяки есть и будут. Не ошибается только тот, кто ничего не делает...
На я привык находить методы и средства для, того чтоб эти ошибки обходить. В худшем случае писать в службу поддержки.
Работая с системой я пытаюсь понять,  как мыслил разработчик, и о чем он думал, давая мне в руки тот, или иной новый инструмент.
В текущий момент, конкретно, меня беспокоит не совсем верный, как мне кажется,  подход к отслеживанию "циклических ссылок". С пример, который, я думаю, уже посмотрел СВ, для того, чтобы обойти этот, ИХМО, "баг", я применил "Компоновочную геометрию", хотя по уму достаточно было бы использовать имеющийся информационный линейный размер. В общем словами это описывать долго и не продуктивно. Речь идет о вот такой ошибке , которая часто возникает, если информационная переменная находится просто ниже по дереву построения, чем использующий её параметр.
PS
Но это здесь, действительно, не в тему..

[beginner]

прошу прощения за офтоп.
по поводу циклической зависимости.
Обращался в СТП с этой проблемой, при тестировании v.20. (суть проблемы в этой теме)
Ошибка была зарегистрирована и вроде как исправлена в 20-ой версии. Не уверен на 100%... времени нет проверить.

[Andy]

Вот когда я об этом еще писал.

[Andy]

Обращался в СТП с этой проблемой, при тестировании v.20. (суть проблемы в этой теме)

Ну да один в один.
Вы нашли способ обхода? Если почитаете сообщение #14, он (способ) там...
Или может быть что то другое нашли? Поделитесь?
Я знаю еще один, но он хуже

[beginner]

Вы нашли способ обхода? Если почитаете сообщение #14? он (способ) там...

Так это же я и придумал этот обход

[Andy]

Так это же я и придумал этот обход

В указанной Вами теме, мягко говоря, немного не так решается вопрос. Я туда добавил свой комментарий.