В сегодняшней публикации речь пойдёт о вставке блоков с использованием MultiCAD.NET API, это один из наиболее часто задаваемых вопросов в программистском разделе нашего форума.

Итак, имеется файл чертежа, который уже содержит блоки-шаблоны для условных обозначений элементов чертежа, например, схемы водоснабжения. Допустим, блоки для представления различных типов кранов содержат два атрибута:

• NAME – название элемента (например, «Шаровый»),
• LABEL – маркировка элемента (например, «11Б27п(М)»),

и имеют следующее графическое представление:

В одной из предыдущих статей мы писали о создании кросс-САПР-платформенных приложений из существующих приложений, работающих только на платформе AutoCAD. В данной статье мы углубимся в детали и расскажем о том, как настроить проект ObjectARX приложения для AutoCAD и собрать NRX приложение для nanoCAD.

Напомним, что для преобразования ObjectARX приложения в NRX приложение необходимо скопировать существующую конфигурацию проекта и заменить в ней пути к заголовкам, библиотекам, а также задать константы для условной компиляции. Процесс этот описан в документации nanoCAD SDK.

Ниже мы расскажем о том, чего в документации разработчика ещё нет — об использовании страниц свойств (property pages), позволяющих минимизировать количество изменений, необходимых для создания в проекте конфигурации для nanoCAD. В результате настройки, приложение можно будет собрать под обе платформы, nanoCAD и AutoCAD, при этом изменения будут вноситься лишь в файлы проектов, исходные тексты, .h и .cpp файлы, останутся неизменными.

В конце октября 2014 года в Москве прошла 10-я юбилейная конференция «Разработка ПО, CEE-SECR-2014», на которой был представлен наш доклад о создании кросс-САПР-платформенных приложений. Доклад состоял из исторического обзора, рассказа об опыте портирования САПР приложений на nanoCAD и анализа основных затруднений при портировании. В настоящей статье мы не будем останавливаться на первых двух частях доклада — запись опубликована в конце статьи, а более подробно рассмотрим третью часть, доработанную по результатам обсуждения доклада в кулуарах конференции.

Когда в 2008 году мы начали разрабатывать nanoCAD, у нас уже существовало более двух десятков приложений для AutoCAD. Работы по портированию приложений велись параллельно с разработкой новой САПР платформы, требования приложений в значительной степени определяли направление разработки. В результате портирования приложения стали кросс-САПР-платформенными, заработали в nanoCAD и не потеряли возможность работы в AutoCAD.

В процессе портирования собственных приложений, а также в процессе общения с разработчиками сторонних приложений в рамках Клуба разработчиков nanoCAD, мы обнаружили несколько повторяющихся шаблонов, мешающих эффективному портированию:

К нам в техподдержку часто приходит вопрос: «Как посчитать суммы длин отрезков (участков трубопровода, элементов электрических схем и т.п.) в чертеже?». Существует масса способов решения этой задачи, в сегодняшней публикации мы рассмотрим реализацию приложения на MultiCAD.NET API, суммирующего длины, которое работает в nanoCAD, AutoCAD и ZWCAD. В качестве примера мы возьмем задачу определения суммарной длины труб в схеме водоснабжения и рассмотрим два варианта выбора элементов для подсчета: пользовательский и по созданному фильтру.

Одной из важных особенностей приложений, написанных на MultiCAD.NET API, является их кросс-САПР-платформенность. Проще говоря, приложения, написанные однажды, могут работать в любой из поддерживаемых САПР без перекомпиляции.

MultiCAD.NET является «родным» API для nanoCAD, приложения могут быть загружены с помощью стандартных команд APPLOAD или NETLOAD. В AutoCAD или ZWCAD необходимо предварительно загрузить MultiCAD Object Enabler, затем MultiCAD.NET приложения загружаются командой NETLOAD.

Под катом пошаговое руководство, в котором мы продемонстрируем процесс загрузки MultiCAD.NET приложения в nanoCAD, AutoCAD и ZWCAD, создадим с его помощью чертеж и отредактируем его во всех трех системах.

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

Механизм управления ручками в MultiCAD.NET позволяет работать как с простыми, так и интеллектуальным ручками. Про простые ручки мы писали в одной из прошлых статей, здесь же мы рассмотрим интеллектуальные ручки, которые, помимо формы (круглые, треугольные, ромбовидные и т.д.), отличаются от простых тем, что они могут изменять отдельные параметры объекта, вызывать всплывающее меню или выполнять набор действий, определенный в обработчике. Кроме, этого API интеллектуальных ручек позволяет также создавать и простые ручки, но используя при этом новый, унифицированный подход.

Под катом код создания нескольких видов интеллектуальных ручек объекта и анимированные изображения, демонстрирующие их использование.

В предыдущей статье мы рассказали о подходе, который используется для сериализации пользовательских объектов в MultiCAD.NET API. Тогда мы говорили о принципах применения данного подхода для обеспечения совместимости версий объектов и рассмотрели самую простую ситуацию, когда новая версия объекта получается из предыдущей путем добавления дополнительных полей. Сегодня мы предлагаем вашему вниманию обзор процесса обеспечения совместимости в случае более серьёзных изменений, таких как удаление, переименование полей или изменение их типов.

Каждый разработчик приложений САПР рано или поздно сталкивается с проблемой хранения в чертеже вспомогательной неграфической информации. Это могут быть атрибуты отдельных графических элементов, атрибуты отдельных листов, или же настройки всего чертежа. В отличие от атрибутов блока, эта информация не видна пользователю и применяется для программной обработки чертежей.

На сегодняшний день существует ряд традиционных способов решения задачи: это добавление XData к элементам чертежа, использование XRecord и создание собственных неграфических объектов.

По сравнению с традиционными, механизм создания и хранения неграфической информации в MultiCAD.NET API гораздо компактней и удобней в использовании. Кроме того, он универсален и может быть одинаково применен для различных типов данных в чертеже: графических элементов, листов или самого чертежа. В качестве дополнительной информации могут использоваться данные различных типов.

Как это работает и как применяется на практике смотрите под катом.

При создании пользовательских объектов на традиционном C++ API (NRX в nanoCAD, ObjectARX в AutoCAD) для обеспечения сохранения объектов и чтения их из файла чертежа необходимо в явном виде описывать запись (сериализацию) и чтение (десериализацию) каждого поля. В MultiCAD.NET API применён более привычный .NET разработчикам описательный подход, в основе которого лежит стандартная .NET сериализация.

Применение сериализации, нечувствительной к версии объектов (Version Tolerance Serialization), предоставляет разработчикам более гибкий механизм управления совместимостью объектов разных версий, чем существующий в традиционном C++ API, где предусмотрено чтение предыдущих версий, но чтение файлов «из будущего» невозможно.

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

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

В предыдущих статьях о таблицах в MultiCAD.NET речь шла о программном создании и форматировании таблиц в чертеже, использовании различных типов данных в качестве содержимого, а также о применении шаблонов таблиц. В этой статье мы продолжим рассказ об использовании шаблонов и более подробно рассмотрим API, позволяющий сохранить таблицу во внешний файл в качестве шаблона и загрузить его в чертеж для формирования типовых таблиц. Во второй половине статьи будет рассмотрен процесс обмена данными с Microsoft Excel.

В одной из прошлых статей мы рассказывали о том, как можно создавать пользовательские примитивы с помощью MultiCAD.NET API, взяв за основу пример CustomObjects из SDK. В этой статье мы уделим внимание процедуре поиска и выбора пользовательских объектов и расширим имеющийся пример, добавив возможность выбора одного или нескольких примитивов с помощью инструментария MultiCAD.NET для последующего редактирования. Подробности — под катом.

В предыдущей статье мы познакомили вас с примером использования табличного функционала MultiCAD.NET API для автоматического создания отчета по выбранным объектам. Мы намеренно нарушаем хронологию и сегодняшнюю публикацию начнём с создания и форматирования простейшей таблицы. Рассмотрим наполнение таблицы данными в текстовом и числовом формате, а также использование формул. Затем перейдем к добавлению блоков и подтаблиц в качестве содержимого ячеек и завершим статью описанием использования свойств объектов чертежа в качестве динамически изменяемых данных таблицы.

Как можно вручную протестировать API? Наоборот, если есть API, чем плохи модульные тесты? При разработке API nanoCAD-а мы столкнулись с тем, что не весь API можно протестировать при помощи модульных тестов — часть API неразрывно связана с пользовательским интерфейсом и интерактивным взаимодействием с пользователем.

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



По мотивам доклада на конференции SQA Days-12.

Этой публикацией мы открывам цикл статей про возможности и особенности API для работы с таблицами в MultiCAD.NET.

Как известно, практически ни один чертеж не обходится без табличного оформления: таблицы применяются для создания объектов, содержащих количественную информацию о конструкции, ведомостей элементов, спецификаций и др. Типичной задачей, с которой сталкиваются проектировщики, является формирование табличного отчета по выбранным объектам чертежа. Автоматизация этой задачи позволит избавить пользователя от рутинной работы, тем самым сократив затраченное время и количество ошибок.

В качестве примера рассмотрим формирование итоговой ведомости электроприборов по плану расположения оборудования (или, проще говоря, по чертежу, иллюстрирующему распределение электрических розеток по помещениям).

В предыдущей статье мы писали о том, как импортировать точки из внешнего текстового файла в .dwg чертеж при помощи классического .NET API. В данной статье мы рассмотрим особенности решения этой же задачи на кросс-САПР-платформенном MultiCAD .NET API и продемонстрируем, как построенное приложение может быть запущено в nanoCAD и в AutoCAD без изменения настроек проекта и перекомпиляции.

Одним из наиболее популярных вопросов по программированию под nanoCAD является «Как мне импортировать точки из текстового файла?». Задача это несложная, но профессиональный проектировщик не обязан быть профессиональным программистом, поэтому эту статью мы написали в стиле «для начинающих».

Импортировать координаты в чертёж можно на любом из существующих в nanoCAD видов API. Мы решили выбрать .NET и сравнить два близких API: классический .NET API и кросс-САПР-платформенный MultiCAD.NET API. Под катом — первая часть — импорт точек на классическом .NET API.

Одним из главных недостатков традиционного .NET API в .dwg совместимых САПР является невозможность создания пользовательских примитивов (Custom Entities) на .NET. Пользовательские примитивы создаются на С++, для их использования в .NET необходимо создать управляемые обёртки на C++/CLI.

Технология MultiCAD .NET позволяет создавать пользовательские примитивы, не выходя за рамки управляемого кода. Помимо отсутствия промежуточных объектов на C++, в MultiCAD .NET максимально используются стандартные для .NET механизмы, как следствие нет необходимости во многих привычных для САПР программистов операциях: не нужно вручную описывать сериализацию, свойства в инспектор можно вывести без создания COM объекта и т.п.

В качестве демонстрации MultiCAD .NET мы рассмотрим пример приложения CustomObjects, содержащийся в комплекте поставки SDK. Этот пример создает пользовательский примитив, который представляет собой прямоугольную рамку с находящимся внутри текстом:



Чертежи, содержащие наш тестовый примитив, могут быть открыты в любой .dwg совместимой САПР. Для изменения примитива необходимо загрузить сборку, содержащую код примитива, причём во все поддерживаемые САПР платформы загружается одна и та же сборка без перекомпиляции. Технология является родной для nanoCAD, для загрузки модуля в AutoCAD требуется модуль расширения (Object Enabler). Как это работает смотрите под катом.