[Salt]

Т.е. некое .NET приложение, загружаемое при старте AutoCAD, экспортирует лисп-функцию (load-аssembly "Путь") назначение которой загружать указанную в аргументе .NET сборку через Assembly.LoadFrom(). Вопрос, можно ли безопасно обращаться к этой функции из кода, выполняемого при загрузке в документ файла *.mnl ? Вроде как лисп интерпретатор уже полностью готов к бою и даже выполняет код (из файлов .mnl, в частности). Но это лишь моё предположение. Поправьте, если ошибаюсь.

[gomer]

может стоит для начала попробовать?

[Кулик Алексей aka kpblc]

Вопрос в том, как выполняется загрузка .NET-сборок (там же вариантов больше одного). Возможно, спасет http://adn-cis.org/search.html?query...B7%D0%BA%D0%B0

[Salt]

может стоит для начала попробовать?

Ну, допустим, попробовал. Получилось. Если сто раз получилось, то это совершенно не означает, что получится на стопервый.

Вопрос в том, как выполняется загрузка .NET-сборок

Через лисп-функцию (экспортированную из .NET приложения, загруженного при старте AutoCAD), внутри которой идет обращение к Assembly.LoadFrom(). А лисп функция вызывается из .mnl. В том и вопрос: безопасно ли обращение к внешней лисп-функции из файла .mnl

[hwd]

Сообщение от Salt Ну, допустим, попробовал. Получилось. Если сто раз получилось, то это совершенно не означает, что получится на стопервый.

жить вообще опасно: можно уснуть и не проснуться, хотя до этого тысячи раз просыпался удачно.

[Salt]

жить вообще опасно

Я всего лишь о том, что если попробовал и не получилось, то тут всё ясно. А вот если получилось, то это еще ничего не означает.
Например, у меня получалось вызывать (command ...) из acad*.lsp, но автодеск категорически не советует это делать.

[gomer]

Сообщение от hwd жить вообще опасно: можно уснуть и не проснуться, хотя до этого тысячи раз просыпался удачно.

Главное праймом не тестить

Сообщение от Salt Например, у меня получалось вызывать (command ...) из acad*.lsp, но автодеск категорически не советует это делать.

А еще, раньше, перед использованием лиспов в пустом документе раисовали точку в начале координат, пещерные люди...

[Salt]

Я хочу иметь самодельную функцию (netload "Путь"), которую можно вызывать из .mnl и использовать её вместо (command "_netload"...), которую нельзя вызывать из .mnl.
Причем тут пещерные люди в начале координат? Гомер, ложись спать, плиз.

[Александр Ривилис]

Salt
Можно. В момент загрузки mnl-файла lisp-подсистема уже полностью инициализирована. Во всяком случае во всех существующих версиях AutoCAD.

[Дима_]

А нормальные способы автозагрузки никак. Если смущает что заработает, но вдруг способ кривой - то у Вас именно такой, но скорее всего работать будет.

[Александр Ривилис]

Сообщение от Дима_ А нормальные способы автозагрузки никак.

Нормальные - это какие? Я так понимаю, что Salt добивается загрузки .NET-сборок в зависимости от (одному ему известных) условий. Так что ни запись в реестр, ни автозагрузчик (который поддерживается только в трех последних версиях AutoCAD) ему не подходят. Какие еще варианты?
IMHO его вариант совсем не кривой. Я неоднократно его использовал (но не в AutoCAD .NET API, а в ObjectARX).

[Дима_]

Сообщение от Александр Ривилис Я так понимаю, что Salt добивается загрузки .NET-сборок в зависимости от (одному ему известных) условий... Я неоднократно его использовал.

Если не секрет что за условия могут выявиться в процессе запуска автокада (то есть не до - когда можно просто изменить конфигурацию, не во время работы - когда это можно "безболезненно" выполнить через тот-же лисп) и которые нельзя проверить из той сборки которая инициализирует лисп функцию загрузки сборок.

[Александр Ривилис]

Дима. Ну этот вопрос скорее нужно было адресовать не мне, а Salt. У меня была ситуация, когда в зависимости от того запускался ли AutoCAD или AutoCAD Architecture и можно ли было загружать и использовать OMF-приложение. Загружать OMF-приложение, когда оно непосредственно необходимо (например, когда необходимо получать параметры стены/окна/перекрытия), накладно по времени и по тем сообщениям, которые выводит AutoCAD в командной строке, а вот при начальной загрузке оно как-то естественно и не так заметно...
Кстати, есть (в последних нескольких версиях AutoCAD не проверял) следующий подтвержденный баг. Если открыто несколько документов и загружается сборка с атрибутом LispFunction, то lisp-функция будет определена только в том документе, который был активен в момент загрузки сборки. В остальных документах она будет неизвестна.

[gomer]

Сообщение от Salt ложись спать

понятие не имею почему некое нет приложение не может подгружать другое нет приложение

[hwd]

Сообщение от Александр Ривилис Кстати, есть (в последних нескольких версиях AutoCAD не проверял) следующий подтвержденный баг. Если открыто несколько документов и загружается сборка с атрибутом LispFunction, то lisp-функция будет определена только в том документе, который был активен в момент загрузки сборки. В остальных документах она будет неизвестна.

Насколько мне известно, атрибут LispFunction не может быть назначен сборке в целом, подобно тому, как это делается с помощью атрибутов CommandClass и ExtensionApplication. На всякий случай повторно просмотрел сигнатуры конструкторов - не вижу такой, которая работала бы по принципу указанных мною выше атрибутов.

Теперь насчёт бага. Я написал следующий простой "Hello World!":

Код:

[Выделить все]

using cad = Autodesk.AutoCAD.ApplicationServices.Application;
using Db = Autodesk.AutoCAD.DatabaseServices;
using Ed = Autodesk.AutoCAD.EditorInput;
using Rtm = Autodesk.AutoCAD.Runtime;

[assembly: Rtm.CommandClass(typeof(LispFunctions.Commands))]

namespace LispFunctions
{
    public class Commands
    {
        [Rtm.LispFunction("test")]
        public Db.ResultBuffer test(Db.ResultBuffer buffer)
        {
            Db.ResultBuffer result = default(Db.ResultBuffer);
            Ed.Editor ed = cad.DocumentManager.MdiActiveDocument.Editor;
            ed.WriteMessage("Hello from .NET!\n");
            return result;
        }
    }
}

Затем в AutoCAD 2014 x64 Enu создал три документа и загрузил тестовую сборку. Lisp-функция (test) доступна во всех трёх документах. Затем создал четвёртый документ - функция доступна и в нём.

P.S. Дополнительно запустил код в AutoCAD 2009 x64 SP3 Enu: да, в этой версии Lisp-функция доступна только в документе, в контексте которого была выполнена загрузка библиотеки. Остальные открытые документы не имеют к ней доступа. Если создать очередной новый документ, то в нём функция будет доступна. Т.о. придётся закрыть все остальные документы и снова открыть их, чтобы функционал был доступен и в их контексте.

Значит баг всё же исправили, только я не знаю в какой именно версии (проверить не могу).

[Salt]

Salt Можно...

Спасибо. Я пока пытаюсь представить общую картину, чего можно, а чего нельзя. Приложение-менеджер должно грузить пул из других приложений и один из рассматриваемых вариантов - это автоматическая генерация .mnl, где для каждого приложение из пула будут прописаны инструкциии вида:

Код:

[Выделить все]

(arxload ...)
(netload ...); самодельная
(load...)

Не знаю пока, насколько это важно, но данный способ в случае смешанных lisp, arx, net приложений позволяет сохранить порядок загрузки файлов в том виде, в каком его определил автор приложения. Порядок так же может быть важен (гипотетически) если .net или arx приложение уже при загрузке использует функционал другого ранее загруженного лисп-приложения (например вызывает функции, зарегистрированные через c: или vl-acad-defun).

Если открыто несколько документов и загружается сборка с атрибутом LispFunction, то lisp-функция будет определена только в том документе, который был активен в момент загрузки сборки. В остальных документах она будет неизвестна.

Я предполагаю, что головная сборка-менеджер будет грузиться при старте автокад (используя соотв. запись в реестре), т.е. до того, как откроется первый документ. А это значит что экспортируемая ею функция (netload...) будет доступна в каждом открываемом документе.

[Дима_]

в 2010 баг LispFunction еще тоже рисутствует...

[hwd]

Сообщение от Salt Я предполагаю, что головная сборка-менеджер будет грузиться при старте автокад (используя соотв. запись в реестре), т.е. до того, как откроется первый документ.

Если бы это было так, то по идее, в методе Initialize вызов editor.WriteMessage сгенерировал бы ошибку, но по факту в консоль документа сообщение выводится. Соответственно к этому времени, как минимум активный документ уже полностью инициализирован. Мой автозагрузчик плагинов (.NET\ARX\LISP\VBA) в методе IExtensionApplication.Initialize активно выводит в консоль AutoCAD сообщения о ходе загрузки (что загружено успешно, а что нет и если "нет", то почему). Настройки загрузок читает из конфигурационного XML. Около 200 пользователей нашей компании юзают его ежедневно. Плагин работает уже несколько лет и грузится через реестр. До сих пор сбоев не было, хотя Александр Наумович ранее писал мне, что такая ситуация возможна и он с ней сталкивался. Однако он пишет на native C++, а я, преимущественно, на C#. Возможно в этом причина разных результатов.

Сообщение от Salt Не знаю пока, насколько это важно, но данный способ в случае смешанных lisp, arx, net приложений позволяет сохранить порядок загрузки файлов в том виде, в каком его определил автор приложения. Порядок так же может быть важен (гипотетически) если .net или arx приложение уже при загрузке использует функционал другого ранее загруженного лисп-приложения (например вызывает функции, зарегистрированные через c: или vl-acad-defun).

Я считаю, что мухи и котлеты должны храниться отдельно. Файл меню - это файл меню, а фильтрация загружаемых плагинов и порядок их загрузки лучше определять в отдельном файле. Один твой плагин, загружаемый через реестр, анализирует этот файл и выполняет загрузку нужного контента. Такой способ удобен тем, что ты можешь в путях указывать различные переменные, как системные, вроде %AppData%, так и определённые тобой (например %CadVer%, %Platform%), а так же произвольные, определённые пользователем (или тобой) и хранящиеся так же во внешнем файле в виде словаря (ключ-значение).

[Salt]

фильтрация загружаемых плагинов и порядок их загрузки лучше определять в отдельном файле

Разумеется. Но когда определен порядок загрузки, генерируется .mnl файл, через который всё и втаскивается в автокад. Подчеркну, он генерируется не в момент запуска автокада, а в момент добавления очередного приложения в пул (или удаления из пула) через отдельное приложение.
Андрей. По поводу твоего загрузчика я читал вот это. Но здесь сам менеджер плагинов загружается в уже инициализированный документ через s::startup, поэтому не удивительно, что editor готов к бою.
Возможно есть новая версия, где это не так?

[hwd]

Сообщение от Salt Андрей. По поводу твоего загрузчика я читал вот это. Но здесь сам менеджер плагинов загружается в уже инициализированный документ через s::startup, поэтому не удивительно, что editor готов к бою. Возможно есть новая версия?

Это старое ведро, про которое я давно уж и забыл. Конечно же есть более новая версия, которой и пользуемся. Завтра напомни, я как раз из отпуска выйду. Выложу на день в сеть исходники загрузчика и скину тебе в личку ссылку на них.

[Salt]

Буду признателен.

[hwd]

Сообщение от Salt Буду признателен.

Вспомнил: у меня же есть удалённый доступ к рабочему компу. давай сейчас с него тебе вышлю на мыло (обозначь его). Исходники нашёл.

[Александр Ривилис]

Сообщение от hwd Значит баг всё же исправили, только я не знаю в какой именно версии (проверить не могу).

В AutoCAD 2013: http://forums.autodesk.com/t5/NET/tw...e/td-p/3509326

Сообщение от Salt Я предполагаю, что головная сборка-менеджер будет грузиться при старте автокад (используя соотв. запись в реестре), т.е. до того, как откроется первый документ. А это значит что экспортируемая ею функция (netload...) будет доступна в каждом открываемом документе.

А почему бы тебе не сделать функцию (netload ...) на ObjectARX раз ты и на нём пишешь? Функция заведомо будет доступна во всех документах, когда бы arx-приложение не было загружено. Вот готовый код: http://adn-cis.org/kak-zagruzit-iz-n...v-autocad.html

[Salt]

Увы, я не пишу на С++. Да и на С# еле-еле
.NET сборка, заружаемая при старте автокада, по любому успешно экспортирует лисп-функции в первый документ, так же как и во все следующие.