Уточните среду до написания логики
Название Python не гарантирует одинаковое поведение во всех инструментах. Нужно знать версию Revit, используемый движок Python и способ получения активного документа. Пример, написанный для другой оболочки, может предполагать переменные или вспомогательные функции, которых в вашей среде нет. IronPython интегрирован с .NET: после подключения соответствующей сборки её пространства имён и типы доступны сценарию. Но это не означает, что любая библиотека, установленная для обычного Python, заработает без изменений. Зафиксируйте окружение рядом с учебным примером, чтобы отличать ошибку совместимости от ошибки самой задачи.
Опишите выборку человеческим языком
Прежде чем искать элементы, сформулируйте ограничение: например, экземпляры стен в текущем документе. Здесь важны все части. Тип стены и конкретная размещённая стена — разные объекты, а весь документ и элементы выбранного вида — разные области поиска. В Revit API для поиска и фильтрации используется FilteredElementCollector. Фильтры нужно выбирать по смыслу задачи, а не копировать случайную цепочку вызовов. Первый отчёт может содержать количество найденных элементов и их идентификаторы. Неожиданно большой или нулевой результат — повод проверить область и условия отбора до любых изменений.
Не превращайте отсутствие данных в значение
При чтении параметров возможны разные ситуации: параметр отсутствует, значение не заполнено, тип данных отличается от ожидаемого. Их полезно сохранять в отчёте отдельными состояниями. Пустая строка и ноль не всегда означают одно и то же. Представим учебную задачу: найти стены с незаполненной текстовой отметкой. У одной стены параметр есть и пуст, у другой отсутствует, у третьей содержит текст. Если все исключения заменить пустой строкой, первые две ситуации смешаются. Отчёт должен показать, где можно обсуждать заполнение, а где сначала нужно выяснить устройство модели.
Изменение модели — отдельный этап
Изменения документа выполняются внутри подходящей транзакции и поддерживаемого контекста API. Создание объекта Transaction само по себе ещё не начинает транзакцию. После выполнения нужно учитывать результат завершения: вызов команды не равен подтверждённому сохранению изменений в модели. Для учебного сценария сначала формируют перечень предлагаемых изменений, проверяют доступность параметров для записи и используют отдельную тестовую модель. При ошибке заранее определяют, какие изменения откатываются и что попадёт в отчёт. Выбор частичного применения или полного отката должен быть осознанным, а не случайным следствием обработчика исключений.
Попробуйте на практике
Спроектируйте первый сценарий на бумаге, без установки программ и изменения рабочей модели.
- Запишите область: экземпляры стен текущего документа. Отдельно перечислите, что исключено: типы и объекты других документов.
- Создайте три вымышленные строки: элемент 101 — пустая отметка; 102 — параметр отсутствует; 103 — отметка «А».
- Сформулируйте правило отчёта, которое сохраняет все три состояния. Укажите, почему 102 нельзя автоматически считать пустым значением.
- Добавьте план отдельного этапа записи: проверка параметра, тестовая модель, транзакция, контроль результата и отчёт об ошибках.
Как проверить результат. Выборка определена однозначно, отсутствие параметра не смешано с пустой строкой. Между получением отчёта и изменением модели есть явная проверка условий.
Частые вопросы
Почему рабочий пример не запускается в другой оболочке?
В ней могут отличаться движок, версии библиотек и предоставляемые объекты. Сначала сравните окружение и получение документа, затем проверяйте прикладную логику.
Нужна ли транзакция для простого чтения параметров?
Обычно чтение само по себе не требует изменения документа. Но доступ к API всё равно должен происходить из поддерживаемого контекста, а сценарий необходимо проверять для конкретной среды.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.