Autodesk Inventor API. Первые шаги: различия между версиями
Содержимое удалено Содержимое добавлено
ALink (обсуждение | вклад) |
ALink (обсуждение | вклад) |
||
Строка 678:
== Прокси-объекты (Proxy) ==
=== Что такое прокси-объект ? ===
Как уже отмечалось, сборки содержат только ссылки, но не геометрию. На первый взгляд, это противоречит опыту конечных пользователей, которые в Инвенторе создают и редактируют сборки. С их точки зрения геометрия деталей реально участвует в сборках. Например, при наложении зависимости совмещения двух деталей вы вольны выбрать грань детали, не задумываясь, где в действительности находится информация о геометрии этой детали. Примерно так же обстоит дело и при работе с API — вы можете просматривать иерархию сборки, получая доступ к ее компонентам и их содержимому, как если бы они находились на верхнем уровне сборки.
В предыдущем примере с демонстрацией перебора компонентов сборки мы так и делали. Мы могли просматривать все ветви сборки и получать ссылки на любой объект ComponentOccurrence в пределах сборки. Если мы попробуем выяснить положение объекта ComponentOccurrence, ответом будет положение, как если бы он находился на верхнем уровне сборки. Если компонент ссылается на деталь, и мы с его помощью получим ссылку на объект B-Rep, информация о геометрии B-Rep будет возвращаться в контексте верхнего уровня сборки.
Чтобы увидеть, как это работает, вернемся к сборке WheelAssembly. В ней имеются два экземпляра детали Колесо (Wheel). Каждый экземпляр (instance) представлен компонентом ComponentOccurrence. Допустим, мы хотим, чтобы пользователь выделил внешние цилиндрические поверхности каждого колеса. Первый вопрос: каким образом пользователь сможет это сделать, если геометрия деталей не присутствует в сборке? Второй вопрос: если предположить, что мы каким-то образом можем выделить геометрию, как отличить внешний цилиндр одного колеса от внешнего цилиндра другого, если в действительности в детали Wheel существует лишь один внешний цилиндр?
[[Изображение: Proxy_1.jpg| ]]
Ответом на оба вопроса будет — прокси-объекты (proxy). Прокси-объекты представляют объекты в сборке так, как если бы эти объекты на самом деле существовали в сборке. К идее прокси-объектов надо привыкнуть, но как только их концепция станет понятной, работать с ними будет уже нетрудно. Вернемся к цилиндрическим граням колес. Когда вы выделяете в сборке одну из них, вы в действительности выделяете объект FaceProxy. Объект FaceProxy наследуется из объекта Face, поэтому он имеет те же методы и свойства, плюс еще несколько, характерных только для прокси-объектов. С объектом FaceProxy, как наследником объекта Face, вы как правило можете работать как с обычной гранью, и даже не требуется особо задумываться, что в действительности вы работаете с прокси-объектом. Для работы с объектом вы используете те же методы и свойства, отличие лишь в том, что получаемые результаты будут определяться положением объекта в сборке.
Прокси-объект устроен довольно просто. Это путь к объекту. Например, пути к цилиндрическим граням двух наших деталей-колес будут иметь следующий вид:
Wheel:1\CylinderFace
Wheel:2\CylinderFace
Здесь «CylinderFace» представляет реальную цилиндрическую грань детали колеса.
Первая часть пути — компонент, последняя часть пути — действительный объект. В многоуровневой сборке путь будет длиннее, потому что в нем будет много компонентов. В сборке всей машины с четырьмя колесами путь к цилиндрической грани одного из колес имеет вид:
WheelAssembly:1\Wheel:2\CylinderFace
Благодаря пути прокси-объекта, Инвентор в состоянии точно определить, на какой именно объект в сборке вы ссылаетесь.
Прокси-объекты поддерживаются для большого количества объектов. Эта поддержка необходима всякому объекту, который в сборке должен быть выделяемым. На самом деле нам уже приходилось иметь дело с прокси-объектами ComponentOccurrenceProxy — в программе перебора компонентов сборки, но это происходило неявно, поскольку мы могли обрабатывать их как обычные компоненты ComponentOccurrence. Компоненты на верхнем уровне сборки являются обычными объектами ComponentOccurrence. Они на самом деле существуют на верхнем уровне сборки. Когда вы перебираете компоненты в любой из подсборок WheelAssembly, возвращаемые объекты имеют тип ComponentOccurrenceProxy. Это так, потому что эти компоненты входят в сборку не на верхнем уровне, а принадлежат колесным подсборкам. Объект ComponentOccurrenceProxy создает видимость принадлежности компонента верхнему уровню сборки. Если запросить у ComponentOccurrenceProxy его положение, он вернет его в контексте верхнего уровня сборки.
Обычно, при получении прокси-объекта в результате перебора сборки или выбора пользователем, вас нисколько не волнует, что вы работаете с прокси-объектом, а не с самим объектом. Именно в этом и состоит самая замечательная особенность прокси-объектов — они упрощают работу с объектами из различных файлов, обеспечивая видимость, будто все объекты существуют непосредственно в самой сборке, как это и представляется конечному пользователю.
=== Создание прокси-объектов ===
Бывают случаи, когда необходимо создать прокси-объект для передачи его другим методам в качестве аргумента. Чаще всего это случается при программном создании сборки и наложении сборочных зависимостей. Рассмотрим конкретный пример. Пусть имеется болт, который мы желаем автоматически вставлять в сборку. Круглое ребро, указанное на рисунке справа, будет использоваться как аргумент при наложении зависимости. Чтобы легко найти это ребро, когда болт будет уже в сборке, к ребру добавлен атрибут «AutoBolts».
[[Изображение: Proxy_2.jpg| ]]
Рассмотрим внимательнее, что происходит в сборке, изображенной на рисунке справа. Сборка состоит из двух деталей, между которыми мы намереваемся установить зависимость. Предположим, мы уже получили компонент-кубик и, используя механику B-Rep объектов, — круглое ребро отверстия. Поскольку мы добрались до ребра через компонент, это будет прокси-объект EdgeProxy, что означает, что он ведет себя как если бы это ребро действительно существовало в сборке. Теперь нам следует получить объект EdgeProxy для ребра в болте. Для поиска ребра к нему был добавлен атрибут, однако этот атрибут существует в детали Болт, а не в сборке. Если попробовать искать атрибут в сборке, мы его не найдем. На самом деле искать атрибут следует в пределах документа Болт. Поскольку. мы проводим поиск в документе Болт, возвращаемый объект будет действительным ребром, а не его прокси-объектом. API предоставляет нам инструменты для создания прокси-объекта. Пример иллюстрирует доступ к документу детали, запрос на поиск ребра, создание прокси-объекта и, наконец, наложение сборочной зависимости. Предполагается, что у мы уже имеем EdgeProxy для ребра на кубике и ссылку на компонент Болт.
[[Изображение: Proxy_3.jpg| ]]
<source lang=vbnet>
' Доступ к определению компонента Болт из самого компонента Болт.
Dim oBoltCompDef As ComponentDefinition
Set oBoltCompDef = oBoltOccurrence.Definition
‘ Запрос на поиск ребра посредством менеджера атрибутов документа Болт
Dim oAttribManager As AttributeManager
Set oAttribManager = oBoltCompDef.Document.AttributeManager
Dim oObjects As ObjectCollection
Set oObjects = oAttribManager.FindObjects("AutoBolts")
Dim oBoltEdge As Edge
Set oBoltEdge = oObjects.Item(1)
' Создание для ребра прокси-объекта.
Dim oAsmBoltEdge As EdgeProxy
Call oBoltOccurrence.CreateGeometryProxy(oBoltEdge, oAsmBoltEdge)
' Наложение сборочной зависимости.
Call oDoc.ComponentDefinition.Constraints. _
AddInsertConstraint(oBlockEdge, _
oAsmBoltEdge, _
True, 0)
</source>
Пример иллюстрирует ряд важных моментов. В свойстве Definition компонент ComponentOccurrence возвращает объект ComponentDefinition документа, на который компонент ссылается. В нашем случае результатом будет объект PartComponentDefinition детали Болта. Это тот же самый объект ComponentDefinition, который мы получаем как свойство ComponentDefinition документа PartDocument. Всякий раз, когда вы используете свойство Definition компонента, вы покидаете контекст сборки и далее все операции будут выполняться в контексте детали. А имея доступ к документу детали, вы получаете в свое распоряжение весь предназначенный для этих объектов инструментарий API. К примеру, вам доступны на изменение значения параметров, и можно даже добавлять новые конструктивные элементы.
Через свойство Document объекта ComponentDefinition можно получить ссылку на родительский документ определения компонента. В данном случае будет получена ссылка на объект PartDocument болта. В примере этот документ используется для получения доступа к менеджеру атрибутов документа Болт. Он вызывает метод FindObjects менеджера атрибутов для получения ссылки на ассоциированное с атрибутом ребро.
Как только ребро в детали найдено, следует создать прокси-объект для представления этого ребра в сборке. Как уже отмечалось, прокси-объект определяет путь к объекту. В файле детали мы имеем объект, и теперь нам требуется добавить к нему путь, чтобы определить тот же объект, но уже в сборке. Делается это с помощью метода CreateGeometryProxy объекта ComponentOccurrence. На вход метода подается объект, на выходе имеем соответствующий прокси-объект. Метод всего-навсего добавляет компонент к пути прокси-объекта. В итоге мы имеем объект, представляющий ребро в контексте сборки.
Последняя строка примера использует прокси-объект болта и прокси-объект кубика для наложения зависимости вставки.
На вход методу CreateGeometryProxy можно подать и прокси-объект. Именно так формируется многоуровневая сборка. Чтобы ее получить, вы начинаете снизу от самого объекта и затем вызываете метод CreateGeometryProxy на каждом уровне сборки, пока не выстроите полный прокси-путь.
=== Работа с прокси-объектами ===
API содержит также ряд дополнительных инструментов для работы с прокси-объектами. Многие из них полезны не только в обычной работе, но и для первоначального знакомства с прокси-объектами и для отладки программ с прокси-объектами.
Как уже отмечалось, различные прокси-объекты наследуются из соответствующих им действительных объектов. По этой причине они поддерживают все методы и свойства объектов-родителей. Но есть у них два дополнительных свойства, которых у родителей нет — ContainingOccurrence и NativeObject. Свойство ContainingOccurrence возвращает компонент ComponentOccurrence, через который виден прокси-объект. В предыдущем примере свойство ContainingOccurrence прокси-объекта ребра в болте вернет компонент Болт.
Свойство NativeObject возвращает настоящий объект, представляемый прокси-объектом. В нашем примере, свойство NativeObject объекта EdgeProxy вернет дествительный объект Ребро (Edge).
Одним из общих свойств объектов и их прокси является свойство Parent (родитель). Но хотя свойство общее, возвращаемая ссылка указывает на разных родителей. В нашем примере, свойство Parent настоящей грани вернет объект SurfaceBody детали, тогда как Parent прокси-объекта EdgeProxy вернет объект SurfaceBodyProxy, представляющий тело в контексте сборки.
Еще две дополнительных функции — свойство OccurrencePath и метод AdjustProxyContext. Свойство OccurrencePath, поддерживаемое компонентом ComponentOccurrence и его прокси ComponentOccurrenceProxy, возвращает путь к компоненту. Это тот же путь, который использует любой прокси-объект данного компонента.
Метод AdjustProxyContext дает возможность обрезать (trim) путь прокси-объекта. Например, если вы имеете 4-уровневую сборку и прокси-объект грани в контексте сборки, вы можете методом AdjustProxyContext сократить его путь так, чтобы прокси-объект был представлен в контексте одной из промежуточных подсборок.
| |||