ADT, MEP Общая Длина элементов по стилям (Страница 6 из 7)

Виктор, спасибо, что ещё?
Думайте, думайте, комрады!!! ))

Виктор,

всё же как-то постарайся объяснить, что за глюки???

Виктор, ...Принято!

Здесь я!
По схемам получается следующее:
1) Необходима интерактивная простановка соединителей в схем.объектах. Хотя бы по принципу, как это делается в параметрических элементах мепа. Ну типа в стиле объекта кнопка вставить соединитель с указанием точки вставки на видовом блоке.
Также мне не хватает метки кривых, которая бы считывала пропертисет и дополнительно была возможность выбора блока (типа круг, овал), для монтажных схем очень нужно. Т.е. в итоге должно получаться на
схем.линии круг или овал или произвольный блок внутри которого значение пропертисета.
Первое что конечно нужно сделать это доработать существующее, что есть. Во первых ручки, с помощью которых отражается объект глючные.
Во-вторых при перемещении схем. элемента на больших схемах получает полная белиберда. Чтобы что-то подвинуть в больших схемам сейчас надо совершить героический подвиг, поэтому мы отказались от применения схем.объектов в схемах соединений, применяем эти объекты только в принципиальных схемах.
В-третьих при большом количестве объектов схема тормозит ужасно, любая регенерация ложит комп минут на 5.
Было бы супер реализовать сх.линии как в визио.
Еще что бесит это глюки аннотативных объектов, особенно во внешних ссылках. Целое дело приходится совершать, когда к устройству приклеена аннотативную марку с выноской. Попробуйте поменять масштаб анотаций передвинуть марку и потом вернуть масштаб. Команда _annoreset с марками она не работает.

Вот еще что полезно:
Необходимо реализовать поле в котором хранится инфа о количестве листов в файле. Для того чтобы например в шаблоне каб.журнала можно было вставлять это поле. Ну типа лист 1 из 50(где 50 это количество листов в файле журнала).

Виталий, я пользуюсь этими свойства, но храню там только состав разработчиков проекта и все идентификационные данные по проекту. Хранение инфы о кол-ве листов на мой взгляд не целесообразно, т.к. это величина часто меняется и отслеживать это сложновато. Я делал реактор на изменение количества листов в файле и записывал значение в пользовательское поле, а в шаблоне проекта ссылался на него. Очень удобно не приходится вручную отслеживать и вероятность ошибки почти нулевая. Где-то в инете можно найти даже исходные коды подобной реализации автор по-моему Бушман Андрей.

Виталий если писать техническим языком, то должно записываться в поле значение параметра layout.count при любой изменении с листами в файле. Значение Этого поля будет обновляться в каждом файле при наступлении заранее заданных событий (реакторов).  Может конечно Вы меня не правильно поняли. Поясню у меня есть файл с общими данными состоящих их нескольких листов, количество листов постоянно меняется, в понимании СПДС общие данные это один чертеж, но может быть разбит на несколько листов, типа ссылочные и прилагаемые документы, ведомость рабочих чертежей и т.п. И кол-во листов реализовано через механизм полей и все это дело автоматически обновляется, не нужно за этим следить. Не нужно будет поля применять к каж. проекту отдельно, т.к. поле будет одно но его значение будет разным в каждом файле. Привызка идет на к проекту, а к каждому файлу, может даже имеет смысл это в голом акаде в поля подшивок добавить.

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

Владимир Петров,

))) да, конечно!!!
Сюда же нужно добавть то, о чём я выше говорил, т.е. в одной структуре MEP выполнить несколько автономных (по обозначениям, нумерации и проч.)проектов. Т.е. управлять как-то шапкой таких проектов, типа шаблонов каких-то придумать и\или диалоговые окна.
Например, модель зд. одна, а проектов по ней м.б. несколько и нужно как-то управлять наименованиями, обозначениями, номерами и проч.
Пожалуй много набирается! И дело даже не в этом, а в том, что они под нас не станут ломать имеющуюся структуру проекта... Что скажешь?

Vitaly

Может я ошибаюсь, но до сих пор в MEP не удалось окончательно "подружить" объекты МЕР (труба и др.) и АА (колонны и др). Т.е. при построении планов и разрезов не удается добиться нормального отображения трубы с осевой и колонн или балок (по видимости). Приходится подключать в отображении элементов модель. Получать нормальные контуры элементов по видимости, а после этого сверху накладывать оси.

Vitaly
AutoCADMEP2010RUS. Для элементов каталогов в конструкторе содержимого для некоторых параметров размера при вычисление необходимо использовать логические блоки типа if...then...else. В дальнейшем что-бы на базе этого элемента создать похожие копируем его, как учит help. Но при копировании пропадает свойство вычисления и появляется ошибка. Приходится открывать hml исходного и конечного файлов в каталоге и вручную копировать необходимые строки для устранения ошибки.

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