LISP из ARX

> Doglexx
В LISP-выражении добавить "(setq xx (Sasha...))", а затем прочитать переменную xx с помощью acedGetSym("xx", ...) и использовать, как хочется.

> Doglexx
1. Использование вызова lisp-функции из arx-приложение - это признак плохого стиля. Причин несколько:
a) аналогичная lisp-функции arx-функция будет выполняться значительно (возможно на несколько порядков) быстрее.
б) передача данных и получение результатов из arx в lisp достаточно затруднено. Если arx-приложение работает в контексте приложения, а не в контексте документа, то lisp-функциями вообще непонятно что будет делать.
2. Если доводы пункта 1. показались не убедительными или нет возможности переписать lisp-функцию (функции) с использование arx, то:
а) использование функции ads_queueexpr(...) в такой ситуации обычно бессмысленно, так как она выполняется ассинхронно к выполнению arx-приложения (т.е. она будет выполнена только тогда, когда arx-команда/функция завершится и AutoCAD получит управление; соответственно получить результат ее выполнения в текущей arx-функции/команде будет невозможно).
б) Есть альтернативы (которые выполняются синхронно): https://www.caduser.ru/forum/topic15242.html

> Н.Н.Полещук
Из всех известных мне интерфейсов (языков программирования) в среде AutoCAD мне кажется (!) оправданным использование двух смесей:
1) lisp->arx (т.е. вызов arx-функция из lisp-функция с возможностью возврата значений)
2) lisp->.NET (и то только начиная с AutoCAD 2007)
Оба интерфейса односторонние, т.е. вызвать lisp-функцию из ARX/.NET достаточно проблематично, а вызов ARX/.NET-функции из lisp-функции не представляет труда.
Когда создавался ADS (прародитель ARX) он был "заточен" на создание на C++ функций, которые можно было вызывать из lisp-программ. Теперь аналогичная ситуация складывается и с .NET.
Все остальные смеси достаточно неустойчивы и (IMHO) не имеют никаких перспектив.

> Doglexx
Так ведь RSRSLT, который Вы выводите, и есть 1.

P.S. Хотя в данном случае все могло быть намного проще:

;;; Lisp'овский код
(defun f1 ( / )
 5 ; Или люб
)
(vl-acad-defun 'f1)

struct resbuf *rb;
wchar_t strres[16];
resbuf *rb_in = acutBuildList(RTSTR,"f1",RTNONE);
resbuf *rb_out = NULL;
int rc = acedInvoke(rb_in,&rb_out);
acutRelRb(rb_in);
if (rb_out) {
 rc = rb_out->resvar.rint;
 acutRelRb(rb_out);
 AcString s; s.Format("%i",rc);
 acedAlert(s);
}

Если необходимо вернуть одно значение, то нет смысла записывать его в lisp-переменную, достаточно вернуть это значение и проанализировать rb_out. Если же значений несколько и их лень объяединять в список и потом его анализировать, то можно воспользоваться lisp-переменными, не забывая делать их имена уникальными (например, при помощи префикса с  именем arx-файла: _T("firstArx_f1") и в lisp-функции (setq fistArx_f1 5)

> Doglexx
1) Загружать lisp-файл ты можешь любым способом (командой APPLOAD, с использованием автозагрузки, lisp-функцией (load ...) и т.д.). Важно чтобы в момент вызова acedInvoke этот код был уже загружен.
2) Причин того, что rb_out остался NULL, может быть несколько:
а) Функция f1 в этот момент не определена.
b) acedInvoke вызвана из контекста приложения, а не контекста документа.
c) произошла ошибка в функции f1
d) ... и т.д
Проверь значение rc - если оно не RTNORM значит lisp-функция или не вызвана или в ней произошла ошибка.

> Doglexx
Ты работаешь с AutoCAD 2007 и ObjectARX 2007? Тогда код должен выглядеть так:

resbuf *rb_in = acutBuildList(RTSTR,_T("f1"),RTNONE);
resbuf *rb_out = NULL;
int rc = acedInvoke(rb_in,&rb_out);
acutRelRb(rb_in);
if (rb_out) {
 rc = rb_out->resvar.rint;
 acutRelRb(rb_out);
 AcString s; s.Format("%i",rc);
 acedAlert(s);
}

Обрати внимание на _T("f1") в вызове функции acutBuildList - из-за того что ты передал не уникодовскую строку AutoCAD не в состоянии найти lisp-функцию f1.

> Doglexx
Увы, но на этот раз я писал код без проверки, так что прошу прощения за ошибки... :)

Увы, но компилятор принципиально не в состоянии выловить здесь ошибку - т.к. эта функция с переменным числом аргументов и он (компилятор) не знает типы аргументов, которые могут быть любыми. Это же замечание относится к функциям acutBuildList, acedCommand, acutPrintf и т.д. Так что с ними нужно быть очень осторожным!

В предыдущем сообщении опечатался название файла вместо "tmp.lst" следует читать "tmp.lsp".

> Doglexx
Все палки надо еще раз удвоить, а то пока дойдет до среды LISP, ничего не останется... (\\\\)