Renga API & Dynamo Core. Часть 3 - создание новых свойств, присвоение объектам, транзакции.

В предыдущей части я остановился на том, что мы закончили рассмотрение "как читать свойства" и остановились на том, как их менять, создавать и присваивать объектам (в рамках особых "транзакций").

Начало и части "после" смотри по ссылкам ниже:

«Renga API & Dynamo Core. Часть 1 - понятие документа, пакетные операции экспорта в IFC и вывод чертежей».

«Renga API & Dynamo Core. Часть 2 - интерфейсы, константы, свойства, чтение свойств; выборка объектов модели и их свойства».

Дальше:

«Renga API & Dynamo Core. Часть 4 - объекты, уровни, стили отображения и COM-типизация данных».

«Renga API & Dynamo Core. Часть 5 - геометрия объектов, общие выводы»

1. О создании свойств и текущих проблемах

В отличие от чтения, для инициации свойства нам потребeтся новые сущности. Первая из них это PropertyDescription (совокупность имени и типа параметра), при этом обратим внимание что уникальный идентификатор guid назначается автоматически (при работе с прогарммой). В случае же с API он вносится как генерируемый пользователем при инициации свойства в проекте Renga. То есть механика внесения нового свойства состоит из трех операций:

1. CreatePropertyDescription() - выбор имени и типа данных для свойства;
2. RegisterProperty() - регистрация свойства в проекте (используя полученный на шаге 1 объект (интерфейс) IPropertyDescription и генерируемый Guid);
3. AssignPropertyToType() - назначение свойства категории объектов по идентификатору свойства (нашему заданному Guid).

Попробуем это реализовать?

Инициализируем определения свойства

Создаем определения свойств в БД модели

Здесь, правда, получится нехорошо - вследствие, перезапусков Dynamo в модель вносится (при сохранении модели) много пустых определений свойств .. и по-хорошему, их бы чистить.

А вот дальше наступают сложности - так как стандартно, методы API подразумевают добавление свойств для объектов модели ... как назначать их (и можно ли вообще) свойствам проекта я задал вопрос в sd.askon .. потом дополню статью на этот счет.

А узнать категорию объекта я не могу так как обратная операция (получение PropertyDescription из свойства) выбивает исключение:

Вот та другая ошибка :((( о которой тоже рапортовал

2. Присваиваем свойства объектам

Здесь (вот отношении объектов) здесь проще. Выбираем категорию и задаем свойства объектов, после чего в рамках транзакции заполняем эти свойства.

Вот так мы создаем определения для свойств (2 шт строчного типа) и присваиваем их категории "Стены"

Параллельно с этим мы делаем выборку объектов ,в которые мы запишем новые свойства

Здесь мы вынуждены считаться с логикой Dynamo тем, что после внесения свойств в объекты мы должны их повторно запросить (так как свойства обновились). Для этого я получу идентификаторы объектов (IModelObject.Id) в отдельный список:

Вот список идентификаторов (int) объектов

Этот список будет подан на вход ноду, который выберет эти объекты из всех объектов и назначит им значения свойств.

Вот так мы назначаем свойства

Картинка общего плана

А вот так выглядит метод, который делает это назначение

Здесь как раз настал черед транзакций - то в рамках чего происходит в том числе назначение свойств.

3. Транзакции в проекте

Не уверен как они называются правильно; будем их так называть по аналогии с продуктами Autodesk; но в Renga они имеют тип IOperation. Если следовать справке (см. ссылку выше):

This class [IOperation] contains functions to commit changes in objects to project.

Что буквально можно перевести как класс .. содержащий функции для подтверждения изменений объектов в проекте.

Окей, какие есть у него свойства?

IOperation.Start() и IOperation.Apply() -- это аналог Ревитовских/автокадовских TransactionManager.StartTransaction() и Transaction.Commit()

Но есть ещё третий аргумент класса Rollback(), который есть не что иное как отмена изменений. В целом, механика действий этого класса емко раскрыта в следующих строках:

Описание работы методов класса

На этом собственно, понятие транзакций и заканчивается :(

Возможно, среди API есть ещё служебные записи/классы, но мне пока не встречались.

4. Изменение свойств объектов

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

Также делается выборка объектов, по ним получается набор IProperty

Из IProperty получают набор идентификаторов, по которым запрашивается PropertyDescription, далее узнается, в какой очередности они идут ... заполняется список значений на замену и также заменяется.

Показать результат не смогу из-за этого.

Вот та ошибка

5. Завершаем?

Да, получилось очень коротко ... на текущий момент я ограничен функционалом API в части создания/изменения расчетных свойств или параметров.

Существующая проблема получения PropertyDescription ограничивает в возможности менять существующие свойства (надеюсь, получится решить при содействии службы поддержки Renga и дописать статьи).

В остальном .. как вы могли заметить, механика назначения свойств объектам несложная. Вдобавок к назначению свойств мы также коротко прошли по свойству и процессу транзакции к проекту Renga.

В следующей части я наконец-то займусь самым хардкором - геометрией ... хардкором потому, что для её отображения как минимум надо будет свои методы, приводя её к геометрии Dynamo (без потери топологии, конечно, при возможности).

Попробую реализовать геометрический класс из Renga API для работы с ней. В общем, не прощаюсь, увидимся в следующей части :d

Не пропускайте публикации, подписывайтесь на Telegram-канал с тизерами статей.

#dynamo core #renga #renga api #rengabim #dynamo