средства разработки sdk в компас что это
Решения
Сегодня встречаются задачи, решение которых не реализованы в CAD-системах. Чаще всего это очень узкоспециализированные задачи, которые встречаются на каком-то конкретном предприятии или подотрасли. Для решения подобных задач вы можете использовать КОМПАС-3D как платформу и на базе него создать свое приложение, которое позволит вам автоматизировать решение таких задач. Для создания таких приложений в КОМПАС-3D есть открытый API.
Более того, вы можете использовать геометрическое ядро C3D, которое компания АСКОН разрабатывает с 1995 года в составе системы трёхмерного моделирования КОМПАС-3D. На сегодняшний день ядро C3D является отдельно лицензируемым инструментом разработчика программного обеспечения и предназначено для использования в программных продуктах в качестве базового компонента, который отвечает за построение геометрической модели и управление построенной моделью. Наиболее известный класс таких программных продуктов — это системы автоматизированного проектирования, в частности системы проектирования (CAD), расчётные пакеты (CAE) и системы подготовки производства (CAM) моделируемых объектов. Геометрическое ядро C3D объединяет в себе три важнейших модуля САПР: геометрический моделировщик, решатель геометрических ограничений и конвертор данных. Применение всех трёх модулей позволяет повысить надежность и быстродействие разрабатываемых приложений.
Кроме решения задач предприятия API и ядро C3D подходят для создания коммерческих продуктов, которые будут расширять возможности КОМПАС-3D.
Для программной обработки объектов КОМПАС-3D можно использовать KOMPAS-Invisible.
Работа с API КОМПАС-3D → Урок 3 → Корректное подключение к КОМПАС
В предыдущих уроках по API КОМПАС (Напоминаем, что в качестве среды используется C++ Builder) Основы и Оформление чертежа мы исходили из того, что КОМПАС не запущен, и запускали его сами методом CreateInstance. Но что если в момент вызова этого метода КОМПАС уже запущен? Тогда будет создан еще один экземпляр данной программы. В принципе ничего страшного, но неаккуратно. Зачем плодить копии программы, когда можно обойтись одним экземпляром?
Сегодня мы поговорим о том, как подключаться к уже запущенному КОМПАС, чтобы не создавать картину, похожую на ту, которая изображена на рисунке ниже.
Запущено несколько экземпляров КОМПАС-3D
Подключение к КОМПАС
Для подключения к программе КОМПАС используется метод ActiveInstance. Ниже приводится пример программы, подключающейся к КОМПАС.
Единственный параметр метода ActiveInstance – строковое наименование интерфейса, к которому мы подключаемся, в кодировке Unicode.
А что будет, если в момент вызова этого метода КОМПАС не запущен? Произойдет ошибка. Причем пользователю будет показано сразу два окна с ругательствами.
Первое окно с ошибкой
Второе окно с ошибкой
Формат этих окон зависит от используемой среды разработки и может отличаться от приведенных выше. Оборачивание вызова метода ActiveInstance в блок try/catch, к сожалению, не решает проблему.
Мы избавляемся только от одного окна с ошибкой. Получается, что вызывать метод ActiveInstance можно только тогда, когда КОМПАС запущен. И здесь мы приходим к главному вопросу: как определить, запущен КОМПАС или нет? Для этого существует несколько методов.
По главному окну
Самый распространенный способ – с помощью функции FindWindow найти главное окно программы. Функция FindWindow ищет окно по его заголовку или по наименованию его оконного класса. К сожалению, она требует точного совпадения строк. Искать по части строки она не умеет.
Заголовок окна мы не можем использовать, так как он включает в себя версию КОМПАС, которая заранее нам неизвестна, и дополнительную информацию, например, наименование открытого документа. Поэтому мы не можем знать наверняка точную строку в заголовке окна. Попробуем по наименованию оконного класса.
Узнать его можно с помощью программы Spy++. На рисунке ниже приведена примерная информация об оконном классе (наименование обведено в красный прямоугольник).
Окно «Свойства окна»
Наименования оконного класса мало того, что не отличаются наглядностью, так еще и различаются в разных версиях КОМПАС. Поэтому поиск по наименованию оконного класса нам также не подходит.
Единственное, на что мы хоть как-то можем положиться, так это на наличие подстроки «КОМПАС-3D» в заголовке главного окна. Но функция FindWindow не умеет искать по подстроке. Единственное, что нам остается, так это перебрать все окна верхнего уровня и проверить, содержит ли заголовок какого-либо из них подстроку «КОМПАС-3D». Ниже приводится исходный код процедуры, осуществляющей эту проверку.
Для перечисления окон используется функция EnumWindows, входящая в состав Windows API. Данная функция подготавливает список окон верхнего уровня и для каждого найденного окна вызывает пользовательскую функцию EnumWindowsProc. В данной функции мы читаем заголовок найденного окна и проверяем, содержит ли он подстроку «КОМПАС-3D». Если содержит, то окно найдено и останавливаем поиск, если нет – переходим к следующему окну. Ниже приводится пример использования данной процедуры.
К сожалению, данный метод очень ненадежен. Дело в том, что в системе могут быть другие окна, содержащие в своем заголовке подстроку «КОМПАС-3D». Пример такого окна приведен на рисунке 4. Это явно не то окно, которое мы хотим найти.
Окно справки
По процессу
Другим вариантом является поиск процесса КОМПАС. У программы КОМПАС исполняемый файл обычно именуется «kompas.exe» (в разных версиях может различаться регистр). Что если вместо окна искать процесс с таким наименованием исполняемого файла? Ниже приводится исходный текст программы, реализующей данный метод.
В данном примере для перечисления процессов используются функции CreateToolhelp32Snapshot, Process32First, Process32Next, входящие в состав Windows API. Для их использования необходимо подключить заголовочный файл tlhelp32.h. Это не единственный способ перечисления процессов, но один из самых простых. Для сравнения строк используется функция strnicmp, которая сравнивает строки без учета регистра символов.
Способ, основанный на поиске процессов, надежнее поиска окна. Он дает значительно меньше ложных срабатываний, но не исключает их. Что если на компьютере пользователя запущена программа с точно таким же наименованием исполняемого файла? Или в последующих версиях КОМПАС исполняемый файл будет называться по-другому? Во всех этих случаях данный метод не работает.
С использованием технологии COM
Все описанные выше методы громоздки и ненадежны. Поэтому их использование нежелательно. Существует более надежный способ проверки факта запуска программы КОМПАС. Он основан на функциях библиотеки ole32.dll, которая входит в состав Windows и реализует технологию COM. Ниже приводится исходный код процедуры, проверяющей с помощью этих функций, запущен ли КОМПАС.
Основную работу выполняет функция GetActiveObject. С ее помощью мы пытаемся подключиться к КОМПАС. Если это удалось, значит, КОМПАС запущен. Функция CLSIDFromProgID используется для конвертирования строкового представления объекта в его CLSID (уникальный 128-битный идентификатор). Ее можно использовать для проверки того, установлен КОМПАС на компьютере пользователя или нет. Ниже приводится пример программы, реализующей такую проверку.
Корректное подключение
Ниже приводится исходный текст программы, реализующей корректное подключение к КОМПАС.
Переменная ObjectName объявлена глобальной, чтобы избежать ее дублирования в разных функциях.
Заключение
В данной статье были рассмотрены различные методы определения того, запущен КОМПАС или нет. Вы можете использовать любой из этих методов или их комбинацию. А может быть, придумаете свой метод. Самым надежным является метод, основанный на функции GetActiveObject.
В конце статьи приведен пример программы, реализующей подключение к КОМПАС с проверкой на его наличие в системе и работу в момент запуска программы.
Сергей Норсеев, автор книги «Разработка приложений под КОМПАС в Delphi».
Python на службе у конструктора. Укрощаем API Kompas 3D
Работая в конструкторском отделе, я столкнулся с задачей — рассчитать трудоёмкость разработки конструкторской документации. Если брать за основу документ: «Типовые нормативы времени на разработку конструкторской документации. ШИФР 13.01.01″ (утв. Минтрудом России 07.03.2014 N 003)», то для расчета трудоёмкости чертежа детали нам необходимы следующие данные:
Из имеющихся инструментов на предприятии имеем: Kompas 3D v14 и Python 3.5.
В интернете не так много статей о написании программ с использованием API Kompas 3D, и ещё меньше информации о том, как это сделать на Python. Попробую рассказать по шагам, как решалась поставленная задача и на какие грабли приходилось наступать. Статья рассчитана на людей, владеющих основами программирования и знакомых с языком Python. Итак, приступим.
Подготовительная операция:
Убедитесь, что на вашем компьютере установлена программа Kompas 3D, версии не ниже 14 и Python 3. Вам также необходимо установить pywin3 (Python for Windows extensions).
Подключение к Kompas 3D:
Система Kompas 3D имеет две версии API: API5, которая предоставляет интерфейс KompasObject, и API7, предоставляющая интерфейс IKompasAPIObject. API версии 5 и 7 во многом дублируют свой функционал, но, со слов разработчиков, в 7-ой версии более выражен объектно-ориентированный подход. В данной статье акцент сделан на 7-ю версию.
Функция подключения выглядит следующим образом:
Чуть подробнее о модуле win32com здесь.
Теперь, чтобы подключиться к интерфейсу, нам понадобиться следующий код:
Для более глубокого понимания API заглянем в SDK. На моём компьютере она находится по адресу: C:\Program Files\ASCON\KOMPAS-3D V16\SDK\SDK.chm. Здесь можно подробнее узнать, например, о методе HideMessage:
После выполнения нашего кода вернём всё на свои места: если Kompas 3D был запущен нами (в процессе работы скрипта), мы его и закроем. Самый простой способ определить, запущен ли процесс, — использовать стандартный модуль subprocess:
Данная функция проверяет, запущен ли процесс «KOMPAS» стандартными методами Windows. Обратите внимание, что разные версии программы Kompas 3D могут иметь разные наименования процессов!
Считаем количество листов и их формат:
Тут всё просто: у нашего документа doc7 имеется интерфейс коллекции листов оформления LayoutSheets. Каждый лист обладает свойством формата и кратности. Для Компаса, начиная с 15 версии, интерфейс LayoutSheets доступен не только для файлов чертежей, но и для спецификаций и текстовых документов.
Посмотрим на процесс изучения SDK для поиска интересующих нас функций:
Читаем основную надпись:
Здесь нам поможет всё тот же LayoutSheets:
На самом деле ячейка №6 для листа с другим оформлением может содержать не масштаб, а совсем иную информацию. Посмотрим, как в Kompas 3D определяются стили оформления чертежа:
Таким образом, важно проверять, какому файлу и номеру оформления соответствует лист чертежа. Также стоит помнить, что документ может содержать титульный лист! Поэтому придётся усложнить код. Применим регулярные выражения, т.к. текст в ячейке может являться ссылкой:
Остался последний вопрос: как узнать нужный номер ячейки? Для этих целей удобно создать файл чертежа, в котором интересующие нас ячейки будут заполнены, а после — прочитать все возможные варианты с помощью следующей функции:
Считаем количество пунктов технических требований:
Согласно SDK, нам всего-то нужно получить интерфейс TechnicalDemand от IDrawingDocument, а
IDrawingDocument можно получить от iDocuments с помощью замечательного метода с говорящим названием IUnknown::QueryInterface. И только в SDK 16 версии Kompas 3D появилось разъяснение, как это сделать:
С такими разъяснениями легко написать следующее:
Стоит отметить, что данный код полагается на автоматическую нумерацию технических требований. Так что, если автоматическая нумерация не применялась или технические требования набраны с использованием простого инструмента «Текст», код будет сложнее. Оставляю решение данной задачи на читателя.
Считаем количество размеров на чертеже:
При подсчёте размеров, надо иметь в виду, что необходимо посчитать их на каждом из видов чертежа:
Основная функция скрипта
В результате проделанной работы мы получили следующее:
Диалоговое окно выбора файлов
Для удобного использования нашего скрипта воспользуемся возможностями стандартного модуля tkinter и выведем диалоговое окно выбора файлов:
Отчётность
Чтобы не рисовать в tkintere интерфейс пользователя, предлагаю воспользоваться хорошей программой Excel, куда и выведем результат нашего труда:
Если не полениться и правильно подготовить Excel файл, то результат работы нашего скрипта можно сразу представить в наглядном виде:
На графике изображено участие каждого сотрудника отдела в выпуске документации на изделие.
Заключение
Используя скрипт для чертежа, созданного специально для данной статьи, мы получим следующие результаты:
Трудозатраты, согласно упомянутому в начале статьи документу, составили: 1 час 20 минут. Как ни странно, примерно столько и было потрачено времени на разработку чертежа.
Конечно, для внедрения подобных норм на предприятии нужны более серьёзные исследования и совершенно другие объёмы конструкторской документации. Данная же статья поможет упростить работу с API Kompas 3D при решении аналогичных задач.
Буду рад любым вашим замечаниями и предложениями к статье.
Работа с API КОМПАС-3D → Урок 1 → Основы
Конструктора и инженеры привыкли работать в КОМПАС, вручную строя чертежи, 3D-модели и сборки. Однако система КОМПАС предоставляет богатый набор функций, позволяющих автоматизировать их работу. При желании весь процесс построения сложного чертежа, 3D-модели или сборки можно свести к нажатию на одну кнопку. Правда для этого придется поработать нам, программистам.
В рамках одной статьи невозможно описать все возможности КОМПАС по автоматизации. Для этого не хватит даже книги. К счастью для нас в комплект поставки КОМПАС входит документация, заголовочные файлы для различных языков программирования и ряд примеров.
Рассказывает Сергей Александрович Норсеев — инженер-программист, АО «ВНИИ «Сигнал», Ковров. Автор книги «Разработка приложений под КОМПАС в Delphi»
Документация и примеры
Документация оформлена в виде одного CHM файла. Он расположен в каталоге SDK каталога КОМПАС. На моем домашнем компьютере, например, полный путь к нему выглядит так: «C:\Program Files\ASCON\KOMPAS-3D v17\SDK\SDK.chm». На рисунке ниже представлено содержимое этого файла.
В этом файле представлено полное описание всех интерфейсов, их свойств и методов. В данной статье мы дадим лишь краткий обзор взаимодействия с КОМПАС посредством COM интерфейсов версии 5.
Дополнительно к документации в комплект поставки КОМПАС входит большое количество примеров программирования под эту систему на разных языках программирования. Они расположены в том же каталоге, что и документация. Открыв каталог «SDK», вы увидите несколько архивов, названия которых соответствуют языкам программирования: «Basic», «C#», «С++» и «Pascal». В них и располагаются примеры. Мы будем использовать язык С++, распакуйте соответствующий архив в любое удобное вам место. В качестве среды используется C++ Builder.
Заголовочные файлы
Перед началом работы нам понадобятся заголовочные файлы. Они находятся в каталоге «SDK\Include\». Нам нужны следующие файлы.
«Ks_TLB.h» и «Ks_TLB.cpp». Они содержат объявления всех основных интерфейсов. Это основные файлы.
«ksConstants.h» и «ldefin2D.h». Это необязательные файлы, задающие различные константы.
После того как эти файлы подключены к нашему проекту, мы можем начать работать.
Подключение к КОМПАСу
Сама система КОМПАС в «API интерфейсов версии 5» описывается интерфейсом KompasObject. Соответствующий ему COM-объект задается строкой «KOMPAS.Application.5». Ниже приводится пример подключения к КОМПАСу.
Тип данных «KompasObjectPtr» задает указатель на интерфейс KompasObject.
В результате работы данной программы на экране появится главное окно программы КОМПАС. В ней не будет открыто ни одного документа.
Для закрытия программы КОМПАС используется метод Quit() интерфейса KompasObject. Одним из самых важных методов интерфейса KompasObject является метод GetParamStruct. Он возвращает указатель на интерфейс параметров объекта того или иного типа. Запрашиваемый тип объекта передается в метод в качестве значения единственного параметра. Всего, согласно документации КОМПАС, через данный метод можно получить 129 интерфейсов параметров для объектов различных типов.
Чертеж и фрагмент
Создание чертежа и фрагмента происходит в два этапа. На первом этапе подготавливаются параметры создаваемого документа. На втором – создается сам документ. Такой двухэтапный подход используется при создании практически всех объектов в системе КОМПАС.
Параметры документа описываются интерфейсом ksDocumentParam. Для получения указателя на него используется метод GetParamStruct интерфейса KompasObject с параметром ko_DocumentParam. Главным свойством этого интерфейса является свойство type, в котором указывается тип описываемого данным интерфейсом документа.
Чертеж и фрагмент описываются интерфейсом ksDocument2D. Получить на него указатель можно с помощью метода Document2D интерфейса KompasObject. Ниже приводится пример программы, создающей новый чертеж.
В результате работы этой программы на экране появится главное окно программы КОМПАС с новым чертежом. Данный чертеж не будет иметь ни рамки, ни основной надписи, так как мы их не настроили.
Для создания фрагмента в поле type интерфейса ksDocumentParam необходимо указать значение lt_DocFragment. Во всем остальном процесс создания нового фрагмента аналогичен процессу создания чертежа.
Спецификация
Создание спецификации похоже на создание чертежа и фрагмента. Здесь тоже используется интерфейс ksDocumentParam. Но есть и ряд отличий. Во-первых, спецификация описывается интерфейсом ksSpcDocument. Указатель на этот интерфейс возвращает метод SpcDocument() интерфейса KompasObject. Во-вторых, в случае создания спецификации необходимо указать полный путь к библиотеке стилей. Если он не указан, то система не создаст спецификацию. Библиотека стилей – это файл «graphic.lyt». Он находится в каталоге Sys\ каталога КОМПАС. Ниже приводится пример программы, создающей спецификацию.
В результате работы этой программы на экране появится окно КОМПАСа с созданной в нем спецификацией.
Деталь и сборка
Деталь и сборка в КОМПАС описываются интерфейсом ksDocument3D. Точнее говоря, этот интерфейс описывает файл, содержащий деталь или сборку. Для получения указателя на интерфейс ksDocument3D используется метод Document3D() интерфейса KompasObject. Ниже приводится пример создания детали.
Отсюда видно, что для создания сборки в приведенном выше примере нужно всего лишь изменить значение второго параметра в методе Create.
В данной статье я показал небольшую часть вершины айсберга под названием «взаимодействие с системой КОМПАС посредством COM интерфейсов». Я лишь показал, как подключаться к КОМПАСУ и как создавать документы всех основных видов (чертеж, фрагмент, спецификация, деталь и сборка). Эти документы создаются без содержимого. О том, как их наполнять будет рассказано в следующих статьях. Следите за новостями блога.
Сергей Норсеев, автор книги «Разработка приложений под КОМПАС в Delphi».
Способы попадания в 3D-цель с помощью API КОМПАС-3D
Введение
Недавно на нашем сайте вышла новость о разработке приложения для КОМПАС-3D, позволяющего автоматизировать процесс моделирования строительных лесов. Уникальность данного приложения состоит в том, что компоненты строительных лесов, добавляемые в сборку, могут автоматически сопрягаться между собой. И это “автосопряжение” не требует от конструктора задавать набор классических сопряжений, лишая компоненты степеней свободы.
Рассказывают:
методист Станислав Ермохин
и инженер-программист Александр Ряполов
На самом деле, нельзя сказать, что мы нашей проектной командой АСКОН-Волга создали что-то неведомое. Программные методы, которые были использованы для реализации функции автоматического сопряжения, давно доступны в API КОМПАС и применяются при разработке многих приложений для системы КОМПАС-3D. Одним из таких часто используемых примеров является приложение Оборудование: Трубопроводы. В нём эта возможность реализована в виде привязки деталей трубопроводной арматуры друг к другу или к трубопроводу.
Приложение “Строительные леса” для КОМПАС-3D
Приложение, которое мы разработали, состоит из двух частей:
каталог элементов строительных лесов, используемых у заказчика;
собственно, программный модуль, который организует процесс сопряжения компонентов между собой.
Во всех этих случаях модуль будет работать с компонентами идентично.
Задачи программного модуля следующие:
отследить, что в сборку вставляется именно компонент строительных лесов;
при перемещении компонента по рабочему пространству поймать в фокусе другой компонент сборки и совместить их между собой согласно инструкции по сборке строительных лесов.
В этой статье рассмотрим, как с помощью API КОМПАС мы решили эти задачи.
Мы за тобой следим.
Это только в статье всё выглядит просто. Но в рамках нашего проекта это оказалось самой “толстой” задачей. Потому как потребовало подробно перечитать инструкцию по сборке строительных лесов, сформировать матрицу точек соединения у всех компонентов и расставить эти точки на моделях компонентов. Хочу заметить, что некоторые компоненты, такие как стойки вертикальные, содержали количество точек, которое приближалось к сотне, так как к этим стойкам можно было навесить множество горизонтальных ригелей и наклонных связей.
В момент, когда мы определялись с точками, сразу договорились, в рамках проектной команды, что наличие присоединительной точки с определенным именем в модели является маяком, который нам необходимо отслеживать и сразу производить последующие действия. И нашем случае приняли, что все точки соединения будут иметь наименование:
Кстати, тем из вас, кто пользовался приложением Оборудование: Кабели и жгуты (КиЖ), данный метод покажется знакомым. И это будет абсолютно верно, так как вариант отслеживания мы подсмотрели там. Только в КиЖ используется дополнительная контрольная точка, а мы сразу отслеживаем наличие присоединительной.
Далее был написан код на C#, который позволил отслеживать процесс вставки в сборку компонентов, считывать наличие присоединительных точек и запускать последующие функции работы с такими компонентами.
Объект obj может быть представлен либо объектом типа ksFeature (объект дерева построения), либо ksFeatureCollection. В последнем случае необходимо перебрать все объекты ksFeature, входящие в коллекцию. Из объекта ksFeature получаем интерфейс добавляемой детали ksPart:
Далее необходимо проверить, что добавляемый объект является объектом строительных лесов. Признаком этого служит наличие у объекта присоединительных точек с обозначением point_NNN.
Не забываем вернуть true в методе перехвата события, чтобы КОМПАС продолжил работу:
Если на этом этапе вам показалось, что слишком много интерфейсов и их преобразований, спешу вас порадовать… дальше еще веселее.
… и прицеливаемся
А вот следующую задачку нам раскусить с наскока не удалось. И тут найти нужную функцию нам помогла наша команда разработки приложений для КОМПАС-3D.
Выяснилось, что для того чтобы отследить положение двух точке в 3D-пространстве, можно использовать два способа:
точное позиционирование по координатам объектов;
позиционирование по лучу взгляда.
Использовать позиционирование по координатам нас сразу отговорили. Монитор-то у нас плоский, а работаем мы с трехмерным пространством. И получается, что, совместив две точки на экране, мы совмещаем их только по двум осям, а третью ось (которая для нас идёт вглубь экрана) совместить не можем, не видя её. И будем вынуждены повернуть пространство, чтобы совместить и эту координату. Вот если бы у нас был плоский чертёж, то была бы красота. Но, увы.
Луч взгляда смотрит перпендикулярно экрану и, условно, преобразует координаты точки объекта на ближайшие координаты экрана. Получается, если мы хотим совместить точки двух объектов, у которых разная глубина расположения перпендикулярно экрану, то эта самая глубина для нас не будет иметь никакого значения. Достаточно точно визуально совместить на экране. Это, как раз, то что нам нужно.
Для сопряжения создаваемого объекта с уже существующим нам необходимо отслеживать изменение координат присоединительных точек нового объекта с теми объектами, что уже есть на сборке. Получение элементов строительных лесов на сборке мало чем отличается от получения создаваемого объекта, с той лишь разницей, что мы получаем объекты не от перехвата событий, а перебираем объекты в дереве построения (на самом деле это сделано заранее, до перехвата события, чтобы не замедлять работу КОМПАС-3D). При запуске приложения мы получили интерфейс KompasObject, посредством которого и получаем дерево построения:
Теперь можем переходить к поиску совпадений. Отслеживаем изменение координат присоединительных точек создаваемого объекта.
Метод GetPoint возвращает координаты в локальной системе координат (в системе координат детали). Для сравнения координат присоединительных точек разных объектов их необходимо привести к какой-то общей системе координат. Логичнее всего использовать систему координат сборки:
Разумеется, всё это проделано и для присоединительных точек тех элементов, что уже присутствуют в сборке. Далее всё просто (если бы), сравниваем координаты присоединительных точек. Для сравнения 3D-координат переводим их в 2D-координаты плоскости экрана с помощью матрицы преобразований, которую получаем перехватом события отрисовки документа
public bool ClosePaint(IPaintObject paintObj)
Далее определимся с названием объектов, имеющих присоединительные точки:
Для пары совпадающих присоединительных точек (естественно, совпадение проверяется в определённом радиусе) выполняем сопряжение “Совпадение”. Направление сопряжения определяется направлением векторов присоединительных точек.
Разумеется, это далеко не весь код. Помимо этого выполняются проверки, как детали могут сопрягаться между собой, например, ригель не может “втыкаться” в ригель, а также проверяется, что точка уже “занята” другим сопряжением, но это уже не относится напрямую к API КОМПАС.
В качестве заключения
В статье мы рассказали, как с помощью API КОМПАС удалось решить две основные задачи при разработке приложения. Конечно, это не все задачи, с которыми мы столкнулись в процессе разработки. Например, мы предусмотрели ситуацию, когда пользователь может не с первого раза попасть в точку совмещаемых компонентов и необходимо делать перебор точек по компоненту. Но эта и подобные задачи решаются написанием соответствующих функции без обращения к API КОМПАС. А в общем случае статья дает представление, как решать задачи отслеживания вставки компонентов и позиционирования в трехмерном пространстве и на экране монитора при реализации собственных приложений.