<quote>
...простите, при чём здесь акад? Тут даже не типы линий, а объекты не будут отображаться...!!!
</quote>
Виталий ну не Вам же мне говорить об использовании eTransmit для этих целей.......
<quote>
Wire - тоже не понятно, зачем её трогать, мы вроде о лотках говорили?
</quote>
Дело в том, что у меня задача реализовать рисование трасс с возможностью подсчета всяких фитингов и трассировки по этим трассам кабелей для подсчета сколько кабеля где идет и для упращения.
Это можно реализовать несколькими способами:
1) Использовать стандартные объекты короба, лотки. Минус их использования не гибкость, зачастую чтобы что-то подвинуть приходится заново рисовать.
2) Доработать для этого какой-нибудь стандартный объект, например провод. 3d виды мне не нужны.
3) Создать свой custom объект с использованием ObjectArx или Overrule .Net Api.
Второй вариант мне нравится тем, что провод можно без больших трудозатрат превратить в нечто-то вроде жгута или трассы для прокладки кабелей. Тем самым реализовать custom диспетчер цепей (диспетчер соединений), если так можно сказать, заточенный под специфику слаботочки. Использование цепей не подходит, т.к. как я понял не возможно к одному объекту подключить несколько цепей.
<quote>
И наконец может быть нужно идти прямым, нормальным путём и просить, требовать от Autodesk добавить ещё одно экранное представление лотка, по ГОСТ!?
</quote>
Я за то чтобы autodesk чего-то сделал, но я уверен, что начинать надо с воздуховодов и труб, например реализовать вместо изометрии в одну линию, аксонометрию по ГОСТ. Я уверен, что львиная доля пользователей меп использует его именно из-за хороших возможностей в части проектирования инженерки(вентиляция, водопровод и т.п.), но им не хватает ГОСТ инструментария. Для проектирования проводов Меп применяется гораздо реже, т.к. разглядеть в нем плюсы для этого сразу очень сложно, лишь разобравшись можно понять что меп много может, чего не могут существующие разработки (типа Project Studio СКС, ОПС и т.п.). А главное его гибкость, одни Property Set Def чего стоят. Что-то ждать для проводов в ближайшие 5лет на мой взгляд бессмысленно, а работать щас нормально хочется.
А по поводу темы, я думаю, что путь использования для целей реализации трасс провода имеет место быть, т.к. 3d нафиг никому не нужен, только усложняет многие моменты. Главное чтоб считалась длина и фитинги...
Я щас провода считаю, тож без использования стандартных объектов типа Shledule Table. Просто создал обычную акад таблицу по форме кабельного журнала связанную с ексел. А длины проводов программно вычисляю (в том числе через внешние ссылки) и експортирую в ексел самодельным експортом, который на мой взляд реализован не хуже чем у Autodeska. Могу собирать таким же способом и длины и штуки для спецификации, чем это хуже применения Shledule Table? Все таблицы акада (КЖ, Спецификация) со связями засунуты в шаблон проекта. Получается замечательно не надо сквозь слезы и тормоза использовать vbscript для того чтобы хоть как-то подружить Shledule Table с длинами и штуками одновременно.
Shledule Table я использую там где она действительно удобна, например условно-графические изображения, всякие таблицы соединений.
