Сообщество программистов Autodesk в СНГ
ADN Club => AutoCAD .NET API => Тема начата: Андрей Бушман от 11-04-2014, 12:00:22
-
Очень плохо, что отсутствует COM API для работы с AcCoreConsole.exe - это не позволяет использовать утилиту программно в следующих ситуациях:
1. Из внешнего приложения быстро создать объект приложения AutoCAD, без мелькания GUI и программно выполнить нужную работу.
2. Из внешнего приложения получить объект уже запущенного консольного приложения AutoCAD и программно выполнить нужную работу.
3. Быстро запускать на выполнение модульные тесты плагинов AutoCAD, написанные при помощи библиотек Gallio (пока приходится пользоваться acad.exe и "три часа" ждать - когда же этот "тормоз" (acad.exe) в очередной раз загрузится).
Если бы GUI-версия AutoCAD запускалась быстро, то отсутствие COM API для AcCoreConsole.exe было бы не так ощутимо. Но поскольку скорость запуска, мягко говоря, ниже плинтуса, то тем острее встаёт обозначенная проблема.
Было бы неплохо поставить в перечень задач реализацию COM API для работы с AcCoreConsole.exe - собственно это и предлагаю.
-
Было бы неплохо поставить в перечень задач реализацию COM API для работы с AcCoreConsole.exe - собственно это и предлагаю.
Пожелание передал.
-
Спасибо.
-
Получил ответ от ADN DevHelp, что пожелание передано разработчикам, но вероятность появления COM в AcCoreConsole мала, так как это приложение стараются делать кроссплатформенным (Windows/Mac), а на Mac понятия COM/ActiveX нет.
-
На MacOS отсутствует и .NET Framework (Mono является дополнительным ПО), однако это не мешает Autodesk во всю использовать WPF при построении графического интерфейса AutoCAD и вряд ли они собираются переползать на кроссплатформенный Qt. Я же не просил реализовывать COM именно для MacOS - понятное дело, что речь о Windows, поскольку тем, кто пишет под эту ОС обозначенный API был бы не лишним. В общем я понял: самостоятельно, через сокеты.
-
однако это не мешает Autodesk во всю использовать WPF при построении графического интерфейса AutoCAD и вряд ли они собираются переползать на кроссплатформенный Qt.
Это только в Windows и на уровне интерфейса, а не ядра. А вот AcCoreConsole - это на уровне ядра, т.е. такое, которое на уровне исходников должно работать и в Windows, и в Mac.
Небольшие размышления. Если добавить в Windows-версию функционал, которого не будет под Mac, то это уже будут совсем разные консоли. Понадобится делать сервер под разные разрядности Windows. И по количеству кода добавление COM-сервера увеличит консоль в несколько (если не в десятки) раз и сделает его "тормознутым, как сам AutoCAD". После этого станет вопрос: "А зачем тогда такая консоль нужна, если можно пользоваться самим AutoCAD без остальных ограничений?".
-
Судя по динамике развития (ее отсутствия) объектной модели автокада - ИХМО врядли - думаю оставят поддержку COM "как есть" - типа неперспективное направление.
з.ы. Андрею по поводу кроплатформености - не очень корректное сравнение - ничто не мешает добавить Mono в общий дистрибутив автокада (оно-же как и сделанно с .Net для виндов) - то есть, оно хоть и дополнительное, но вполне рабочее.
-
Если вместо COM будет какая-то иная реализация (наприме те же sockets, которые присутствуют в любой OS), перекрывающая обозначенные мною выше вопросы, то меня и такая альтернатива вполне устроит. Мне, собственно, важен конечный результат, а как именно его решат реализовать - это уж на откуп разработчиков.
На данный момент мне придётся писать свой плагин, с которым (после его загрузки в accoreconsole) можно будет общаться из внешнего приложения посредством сокетов, передавая команды, которые плагином будут отправляться в консоль (упрощённый вариант взаимодействия). Т.е. действовать в обход отсутствующего COM API.
-
з.ы. Андрею по поводу кроплатформености - не очень корректное сравнение - ничто не мешает добавить Mono в общий дистрибутив (оно-же как и сделанно для виндов) - то есть, оно хоть и дополнительное, но вполне рабочее.
Это я понимаю. В своём тексте имел в виду, что Mono не поставляется "в коробке" с операционкой, а является дополнительным ПО. Я, собственно, всеми руками и ногами "за" Mono.
-
На данный момент мне придётся писать свой плагин, с которым, после его загрузки в accoreconsole) можно будет общаться из внешнего приложения посредством сокетов, передавая команды, которые плагином будут отправляться в консоль (упрощённый вариант взаимодействия). Т.е. действовать в обход отсутствующего COM API.
Ну так сделай свой COM-сервер (как .NET-приложение) и управляй через него AutoCAD. :)
-
Ну так сделай свой COM-сервер (как .NET-приложение) и управляй через него AutoCAD.
Возможно я вас не верно понимаю... Ну и как я с помощью этого COM сервера смогу управлять accoreconsole (сокеты пока не в счёт...)?
-
Если твоё .NET-приложение является COM-сервером и загружено в AcCoreConsole (или в AutoCAD), то обращаясь извне к нему как к COM-серверу ты можешь управлять AutoCAD в той степени, в которой у тебя развит COM-сервер. Об этом неоднократно писал Зуев Сергей Александрович (ShaggyDoc)
-
ты можешь управлять AutoCAD в той степени, в которой у тебя развит COM-сервер
ИХМО "развивать" свой COM сервер под "общие" задачи это утопия (то есть вполне можно, но этим надо "всю жизнь" заниматься - т.к. функционал непрерывно растет). Единственно правильным я вижу настройку интерфейса COM(либо другая технология)->.Net(via Reflection). Я уже писал http://adn-cis.org/forum/index.php?topic=349.msg1028#msg1028 (http://adn-cis.org/forum/index.php?topic=349.msg1028#msg1028) что делал такое на лиспе - но "оно" не похоже на нормальный лисп - а как корове седло - ехать можно, но не красиво и не удобно (из-за разности подхода функционального и императивного программирования) - получилась такая-же халтура как и реализация vla в автолиспе, а сделать нормально - так и не разродился. Но если технологии "родственные" (как в случае с COM), то этой неприятности и не будет как таковой.
з.ы. в любом случае я бы сейчас сильно задумался о настройки интерфейса именно через COM.
з.з.ы. то А. Ривилис - Сергей Александрович по моему "пропагандирует" обратную задачу использовать свой COM сервер "из автокада" - то есть с навешанными "внешними плюшками" для расширения лиспа.
-
з.з.ы. то А. Ривилис - Сергей Александрович по моему "пропагандирует" обратную задачу использовать свой COM сервер "из автокада" - то есть с навешанными "внешними плюшками" для расширения лиспа.
Да. Это действительно разные задачи.
-
Правильно ли я понял, что в AcCoreConsole можно загрузить .NET плагин? Если так, то почему бы не опереться на WCF?
-
Правильно ли я понял, что в AcCoreConsole можно загрузить .NET плагин?
Да. Доступны не все возможности, но достаточно много.
Если так, то почему бы не опереться на WCF?
Тоже вариант.
-
Да. Доступны не все возможности, но достаточно много.
Цитата: Josser от 15-04-2014, 19:25:46
Если так, то почему бы не опереться на WCF?
Тоже вариант.
Согласен. Попробовал, сделал, работает.