Мне удалось добраться только до PressurePartLists...Странно, учитывая, что он тоже internal:
Странно, учитывая, что он тоже internal:Удалось получить только имена PressurePartList. Нашел такое решение - https://forums.autodesk.com/t5/autocad-civil-3d-customization/how-to-access-pressure-network-parts-lists-using-vb-net/td-p/6205962
Информация о типоразмере трубы хранится в свойстве PartDescription (readonly) от базового класса PressurePart.А если вручную на чертеже поменять описание, что будет возвращать PartDescription?
У прародителя, Entity, есть свойство Description, доступное для редактирования. И если изменить Description, то автоматом меняется и PartDescription.
А если вручную на чертеже поменять описание, что будет возвращать PartDescription?В том то и дело, что Description заменяет значение PartDescription даже при ручном редактировании.
Вообще, лучше придерживаться правила: один вопрос - одна тема. А в этой теме это уже 3-й вопрос.Эту задачу можно закрывать. Исследования показали, что присваивание стиля напрямую не актуально. Стилю присваивается значение стиля PressurePartSize. Проверено. Единственное - зачем генерировать исключение, если можно просто сделать ReadOnly.
Получил второй ответ (от разработчиков) - такого функционала в текущих версиях Civil 3D API нет. Создана заявка на добавление такого функционала, но без серьезного ‘business case’ до него руки дойдут не скоро. По поводу ‘business case’: http://adn-cis.org/forum/index.php?topic=2640.0Спасибо! Примерно это я и предполагал после изучения вопроса.
В любом случае если это изменение и будет, то только в новых версиях.
Попробовал DwgOut, заменить ссылку на StyleId в ReferenceFiler и вызвать DwgIn, но попытка не удалась... Может, возможны подобные "танцы с бубном"?Такие "танцы с бубном" теоретически возможны через P/Invoke для функций acdbEntGet/acdbEntMod из ObjectARX.
Такие "танцы с бубном" теоретически возможны через P/Invoke для функций acdbEntGet/acdbEntMod из ObjectARX.
(entget (car (entsel)))
Выберите объект: ((-1 . <Имя объекта: 7ffffb6d580>) (0 . "AECC_PRESSUREPIPE") (330 . <Имя объекта: 7ffffb361f0>) (5 . "77C8") (100 . "AcDbEntity") (67 . 0) (410 . "Model") (8 . "_ГКС ОСВЕЩЕНИЕ СЕТЬ") (100 . "AeccDbEntity") (100 . "AeccDbGeo_aec") (100 . "AeccDbGeo") (100 . "AeccDbNetworkPartBase") (100 . "AeccDbPressurePart") (100 . "AeccDbPressurePipe"))
Кстати, возможно, что от некоторых проблем (например, с метками) можно избавиться, если использовать при замене трубы метод подмены Id:Спасибо, Дмитрий!
Пока не проверил, но скорее всего проблема решается заменой ссылок аналогично http://adn-cis.org/forum/index.php?topic=8112.0 (http://adn-cis.org/forum/index.php?topic=8112.0)Проверь пожалуйста эту возможность. Если это так, то можно будет утереть нос и ADN DevHelp, и команде разработчиков. Хотя я просил у них посмотреть нет ли workaround, но они этот вариант не нашли.
Проверь пожалуйста эту возможность.Проверил. Работает!
Ну и кусочек кода, который это делает.Кусочек:
Неужели "pipe" настолько длинное слово, что его нужно сокращать до "pip"?Отредактировал. Так лучше? :)
Не удалось применить SwapReferences для замены типоразмера.Тут я не совсем понял. Если типоразмер уже в чертеже использовался, то для него уже есть PartDef Id. В этом случае SwapReferences применим. Я так понимаю, что ты не можешь программно создать новый типоразмер, для того чтобы поменять на него.
Надо задавать новый PartDef Id, а библиотека AECC_NETWORK_PART_DEFS содержит PartDef только для уже вставленных объектов.
Я так понимаю, что ты не можешь программно создать новый типоразмер, для того чтобы поменять на него.Напорные объекты содержат ссылки не на типоразмер, а на PartDef. Не понятно, как его создавать...
Напорные объекты содержат ссылки не на типоразмер, а на PartDef. Не понятно как его создавать...Но если он уже использовался (PartDef), то ты можешь на него переключится? Создать ты его действительно не можешь.
Но если он уже использовался (PartDef), то ты можешь на него переключится?Если использовался, то можно. Если новый - остается способ с заменой объекта.