Технология, скрывающая реализацию в каждой конкретной системе и позволяющая запустить одно и то же приложение в разных САПРах есть, называется MultiCAD.NET, см. нашу статью на эту тему: https://habr.com/ru/company/nanosoft/blog/242497/. Правда технология не скриптовая.
LISP в nanoCAD-е есть, загружается привычными способами, командой APPLOAD или по-лисповому (load "my.lsp"). А вот VBA в nanoCAD-е, к сожалению, нет — к появлению nanoCAD-а Microsoft уже не продавал движок VBA новым клиентам. Тем не менее ActiveX/COM API в nanoCAD-е есть, и VBA приложения можно портировать VB.NET. Код переезжает с минимальными исправлениями, а формы приходится перерисовывать, сохраняя названия контролов.
Замечание верное, но лишь отчасти. WINE это не виртуальная машина и не эмулятор, а подсистема Win32 API, работающая поверх ядра Linux. Тема интересная, но в комментариях к данной статье это явно офтопик.
Наш опыт портирования приложений на nanoCAD отчасти изложен в статье habrahabr.ru/company/nanosoft/blog/248753, написанной по мотивам доклада на конференции о кросс-САПР-платформенной разработке. В статью не вошло введение из доклада, посвящённое истории возникновения и развития API клонов AutoCAD-а, но его можно прочитать в презентации или посмотреть в записи доклада, они в конце статьи.
Чтобы скоротать время до первой половины мая, можно почитать статьи про MultiCAD.NET API, приложения на котором работают, в том числе, и под AutoCAD-ом.
Например, можно создать обычную форму Windows с полями ввода, отобразить ее на экране с помощью ShowModal()
Плохой способ, т.к. в этом случае существует вероятность в AutoCAD поймать Fatal Error. Вместо этого следует пользоваться статическими методами класса Autodesk.AutoCAD.ApplicationServices.Application: для WPF это методы ShowModalWindow и ShowModelessWindow, а для WinForms — методы ShowModalDialog и ShowModelessDialog.
Тут дело даже не в Fatal Error, а в том, что упомянутые статические методы собирают список окон, которые автоматически закрываются при вызове Editor.GetPoint() и подобных функций.
Если модель сериализовать целиком, а чертёж использовать только как хранилище «чёрного ящика» сериализованных данных, то конечно выйдет расточительно. Но ведь можно каждый объект модели сериализовать самостоятельно.
Для этого, впрочем, пришлось бы создавать пользовательские примитивы на C++, ведь в 2010 году, когда была написана статья, ещё не было технологии, позволяющей остаться в рамках .NET. О том, как это можно сделать сейчас, мы недавно писали в статье про сериализацию в MultiCAD.NET API.
Обеспечение же синхронизации транзакций обоих типов...
Позволяла ли решаемая задача хранить в чертеже и саму модель, в виде неграфических данных? Тогда транзакция будет одна и необходимость в синхронизации отпадёт сама собой.
Ну как не среагировать на такую подачу? Приведённый пример будет прекрасно работать и под бесплатным nanoCAD.
Попробуйте пересобрать пример, заменив пространство имён Autodesk.AutoCAD на HostMgd, как описано в статье "САПёР на полях САПР". Поскольку используется VS2013, не забудьте выставить TargetFramework=v3.5.
А там, глядишь, и до упомянутой программы для заказчика дело дойдёт.
Мы не пытаемся отвязаться от UI, нам как раз интересно проверить полную цепочку от двух WM_LBUTTONDOWN до возврата угла из GetPoint().
Применительно к данной задаче, действие в UI присходит в GetAngle(), который мы тестируем. PromptAngleOptions лишь содержит входные параметры.
Если бы мы тестировали какую-либо команду, использующую GetAngle(), скажем, команду поворота выбранных объектов, то GetAngle() можно было бы замокать. Но, тогда и процесс запуска команды стоило бы отключить от UI, и предпросмотр результата поворота, и далее до тех пор, пока мок не станет похож на спецсборку nanoCAD-а. Поэтому мы и пытаемся, по возможности, использовать существующие механизмы. UI тестировать через UI, работу с базой данных чертежа — без UI.
Аналогичное преобразование в ObjectARX доступно только из модуля, загруженного в AutoCAD, будь то .NET или C++. Нам же нужно было добраться до этого преобразования снаружи, из внешней системы автоматизированного тестирования. Поэтому мы и расширили COM модель.
Мы совсем не против ATable, работающего под nanoCAD-ом, пользователям от этого только плюс. Тогда можно будет обмениваться чертежами между платформами и они везде будут «живыми», т.е. без мёртвой прокси графики.
Осталось только автора уговорить портировать ATable на nanoCAD, поможете?
Технология, скрывающая реализацию в каждой конкретной системе и позволяющая запустить одно и то же приложение в разных САПРах есть, называется MultiCAD.NET, см. нашу статью на эту тему: https://habr.com/ru/company/nanosoft/blog/242497/. Правда технология не скриптовая.
LISP в nanoCAD-е есть, загружается привычными способами, командой APPLOAD или по-лисповому (load "my.lsp"). А вот VBA в nanoCAD-е, к сожалению, нет — к появлению nanoCAD-а Microsoft уже не продавал движок VBA новым клиентам. Тем не менее ActiveX/COM API в nanoCAD-е есть, и VBA приложения можно портировать VB.NET. Код переезжает с минимальными исправлениями, а формы приходится перерисовывать, сохраняя названия контролов.
Замечание верное, но лишь отчасти. WINE это не виртуальная машина и не эмулятор, а подсистема Win32 API, работающая поверх ядра Linux. Тема интересная, но в комментариях к данной статье это явно офтопик.
Тут дело даже не в Fatal Error, а в том, что упомянутые статические методы собирают список окон, которые автоматически закрываются при вызове Editor.GetPoint() и подобных функций.
Для этого, впрочем, пришлось бы создавать пользовательские примитивы на C++, ведь в 2010 году, когда была написана статья, ещё не было технологии, позволяющей остаться в рамках .NET. О том, как это можно сделать сейчас, мы недавно писали в статье про сериализацию в MultiCAD.NET API.
Позволяла ли решаемая задача хранить в чертеже и саму модель, в виде неграфических данных? Тогда транзакция будет одна и необходимость в синхронизации отпадёт сама собой.
Ну как не среагировать на такую подачу? Приведённый пример будет прекрасно работать и под бесплатным nanoCAD.
Попробуйте пересобрать пример, заменив пространство имён Autodesk.AutoCAD на HostMgd, как описано в статье "САПёР на полях САПР". Поскольку используется VS2013, не забудьте выставить TargetFramework=v3.5.
А там, глядишь, и до упомянутой программы для заказчика дело дойдёт.
Пожалуйста: habrahabr.ru/company/nanosoft/blog/198788/.
Не пример, но очередная статья про таблицы в MultiCAD.NET API.
Применительно к данной задаче, действие в UI присходит в GetAngle(), который мы тестируем. PromptAngleOptions лишь содержит входные параметры.
Если бы мы тестировали какую-либо команду, использующую GetAngle(), скажем, команду поворота выбранных объектов, то GetAngle() можно было бы замокать. Но, тогда и процесс запуска команды стоило бы отключить от UI, и предпросмотр результата поворота, и далее до тех пор, пока мок не станет похож на спецсборку nanoCAD-а. Поэтому мы и пытаемся, по возможности, использовать существующие механизмы. UI тестировать через UI, работу с базой данных чертежа — без UI.
Аналогичное преобразование в ObjectARX доступно только из модуля, загруженного в AutoCAD, будь то .NET или C++. Нам же нужно было добраться до этого преобразования снаружи, из внешней системы автоматизированного тестирования. Поэтому мы и расширили COM модель.
Таблицы ATable это пользовательские примитивы (custom entities) или использован механизм, описанный в статье Создание «нестандартного» кастомного объекта для AutoCAD, работающего без Object Enabler?
Мы совсем не против ATable, работающего под nanoCAD-ом, пользователям от этого только плюс. Тогда можно будет обмениваться чертежами между платформами и они везде будут «живыми», т.е. без мёртвой прокси графики.
Осталось только автора уговорить портировать ATable на nanoCAD, поможете?