[swkx]

Общепринятый способ запуска команд кнопкой меню ^C^C(if (null C:<команда>)(load "<файл>"));<команда>;
в том числе и упомянутый VVA в статье "Как использовать лисп, опубликованный на форуме", иногда не совсем корректен. Ошибка возникает в случае, когда в тексте файлов двух вызываемых программ есть функции, имеющие одинаковое название, но выполняющие различные действия.

Пример. Имеем два файла test1.lsp и test2.lsp

Код:

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

 (defun c:test1 ()
	(func-alert)
)

(defun func-alert ()
	(alert "Test 1")
)

Код:

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

 (defun c:test2 ()
	(func-alert)
)

(defun func-alert ()
	(alert "Test 2")
)

Порядок действий в ком. строке Автокаде:
1. (load "C:\\test1.lsp")
2. test1 - работает правильно
3. (load "C:\\test2.lsp")
4. test2 - работает правильно
А дальше нюансики. Т.к. test1 уже загружена, просто выполняем её:
5. test1 - Ошибка ! Видим на экране окшко "Test 2", т.е. отработала (func-alert) из test2.

Вывод: создав две кнопки с макросами
^C^C(if (null C:test1)(load "C:\\test1.lsp"));test1;
и
^C^C(if (null C:test2)(load "C:\\test2.lsp"));test2;
и во всех похожих случаях имеем шанс нарваться на неприятности, которые усугубляются тем, что проявляются не всегда, а только при частом поочередном использовании кнопок в одном сеансе работы.

Вопрос: не лучше ли при современных объемах ОЗУ всегда использовать в качестве кода макроса конструкцию типа ^C^C(load "C:\\test1.lsp");test1; ?
Есть ли противопоказания у такого подхода ?

[swkx]

Я пример на ходу лепил, только чтобы суть пояснить, поэтому для простоты и нацарапал C:\\test1.lsp

[Vov.Ka]

компили в separate namespace vlx c экспортом только заглавной функции

[hwd]

Сообщение от Dmitrij_Kulikovs С вами полностью согласен. Уже ведь 21 век, а мы все используем старые макросы.

Обновите дату модификации - они сразу станут как новые (современные)

[ShaggyDoc]

Более 20 лет использую загрузку безо всяких if. Это гарантирует, что всегда выполняется именно нужная программа. Никаких торомозов тут нет, даже ещё в AutoCAD R10 (не 2010) даже загрузка очень большой библиотеки происходила очень быстро. Это дает и дополнительное преимущество. Файл всегда можно безболезненно заменить, всегда будет действующая версия.

Более того, много лет использовал для всех программ одно имя команды.

В последние годы использую такую методику:

1. Конечным функциям ("командам") присваиваю "цифровые" имена. Команд тысячи, напридумывать для них человечьи имена невозможно, да их и не запомнишь. А цифры человек запоминает очень легко.

2. В CUI команда записана примерно так:

Код:

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

<Macro type="Any">
  <Revision MajorVersion="16" MinorVersion="2" UserVersion="1" /> 
  <ModifiedRev MajorVersion="17" MinorVersion="1" UserVersion="1" /> 
  <Name xlate="true" UID="XLS_0003">XML: 3D-Трубопроводы 4301</Name> 
  <Command>^C^C^P4301</Command> 
  <HelpString xlate="true" UID="XLS_4113">3D: Прямые и гнутые участки трубопроводов</HelpString> 
  <SmallImage Name="RU_XML_3D_PIPE_LINE_16.BMP" /> 
  <LargeImage Name="RU_XML_3D_PIPE_LINE_16.BMP" /> 
</Macro>

Здесь вызывается команда с именем 4301.

3. Определение команды записано в MNL:

Код:

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

 (defun C:4301 ()
  (ru-xml-pop-mnu  "3d/ru_3d_pipe_lines"  "Трассы трубопроводов")
  (princ)
)

Как видим, суть команды заключается в выполнении библиотечной функции с аргументами.

Там, где требуется загрузка кода из файла команда имеет вид наподобие:

Код:

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

 (defun C:0911 ()
  (ru-app-load "profi/ru_pro_arrange_blocks")
  (princ)
)

Обратите внимание - нет никакого вызова "исполнительной" функции. Он выполняется внутри загруженного файла.

[Дима_]

Сообщение от ShaggyDoc Обратите внимание - нет никакого вызова "исполнительной" функции. Он выполняется внутри загруженного файла.

Откровенно говоря спорный метод - а тогда как у Вас происходит загрузка програмных подфункций (общие-то наверняка есть), они либо в каждом файле продублированны должны быть (уверен на 100% - у Вас не так), либо загружаться при каждом вызове из внешнего файла (а в автолиспе с этим проблеммы - так как пути надо "жестко" прописывать - то есть инсталятору добавляется "ненужной" работы - изменить пути в каждом файле - ну либо инициализировать некую переменную где эти пути прописанны (способ проще но с надежностью потенциальные проблемы), или заставлять грузить "жестко" из какого-нибудь %appdata%\myprogram - тоже не есть гуд т.к. если придеться .net подмешивать (у меня к "сожалению" его все больше и больше) - проблемы с разными версиями (на одном компьютере) возникнут), либо сразу "при старте" должны быть уже загруженны - тогда вобще смысла никакого нет - проще сразу и все c:xxx тоже загрузить.

[Jonas]

Не рискнул создавать тему, может здесь разъясните?
Встречаю различные способы авто-загрузки lisp файлов -

^C^C(if (null C:<команда>)(load "<файл>"));<команда>;
^C^C:P(if (eq C:<команда>)(load "<файл>"));<команда>;
^C^C(if (not C:<команда>)(load "<файл>"));<команда>;
^C^C(load "<файл>"));<команда>;

В чем разница?

[Дима_]

Первые 3 ничем - так сказать богатство языка, последний загрузка без проверки загружен-ли уже лисп.

[ShaggyDoc]

а тогда как у Вас происходит загрузка програмных подфункций (общие-то наверняка есть), они либо в каждом файле продублированны должны быть (уверен на 100% - у Вас не так), либо загружаться при каждом вызове из внешнего файла (а в автолиспе с этим проблеммы - так как пути надо "жестко" прописывать - то есть инсталятору добавляется "ненужной" работы - изменить пути в каждом файле - ну либо инициализировать некую переменную где эти пути прописанны

Все эти "программные подфункции" находятся в файле библиотеки функций. Он постоянно загружается автоматически при работе в определенном профиле - через acaddoc.lsp, т.е. при открытии любого DWG.

Никакие пути не надо жестко прописывать - все вычисляется на лету, относительно папки с установленной системой. Инсталлятор, разумеется, необходим - чтобы не делать никаких ручных настроек. Часть файлов устанавливается в %Program Files%, осовная - в %Local Application Data%. Все настройки хранятся в INI-файле, расположение которого системе известно. Там может быть записано что угодно, в том числе пути к различным компонентам системы.

Могут использоваться и разные версии AutoCAD попеременно. Для каждой версии часть файлов является специфичными, загружаются из своих папок.

В настройки самого AutoCAD никаких изменений не вносится, никакие его файлы не затрагиваются. Только добавляется свой профиль - ради включения дополнительных папок в %ACAD%.

Файл acaddoc.lsp генерируется на лету из специального шаблона. В шаблоне имеется масса "плейсхолдеров", в которые подставляются значения различных переменных. В результате во время работы будут записаны абсолютные пути. После завершения работы acaddoc.lsp уничтожается и никому не мешает.

проще сразу и все c:xxx тоже загрузить.

А их примерно 15000. Зачем их грузить? Они определены в MNL-файлах, которые сами и загружаются при подгрузке соответствующего "фрагментарного" меню. А таких меню сейчас 11 штук (по темам).

если придеться .net подмешивать (у меня к "сожалению" его все больше и больше) - проблемы с разными версиями (на одном компьютере) возникнут

"Проблемы индейцев шерифа не волнуют". Мне до сих пор ни разу не пришлось столкнуться с чем-нибудь, требующим именно .NET. У меня нормальная, обычная, ориентация. Во всех смыслах. Я даже от ARX отказался, когда он стал привязываться к определенным версиям AutoCAD и компилятора VC.

Хотя уверен, что вопрос и с версиями библиотек .NET можно решить. Если подходить с правильной стороны.

[Дима_]

Сообщение от ShaggyDoc А их примерно 15000

15000 команд c:xxx? - тут что-то не так с организацией команд - подумайте сами - слов в русском языке меньше, команды типа c:xxx предназначенны для непосредсвенного исполнения пользователем, столько нету нигде ни в автокаде, ни в операционных системах, ни в msoffice со всеми возможными надстройками.
p.s. из кода:

Код:

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

 (defun C:0911 ()
  (ru-app-load "profi/ru_pro_arrange_blocks")
  (princ)
)

я пологаю что у Вас примерно 15000 тысяч файлов??
p.p.s - откровенно говоря мне с большим трудом верится, что у Вас все 15000 функций абсолютно "разношерстные" - сильно-ли отличается из Вашего примера "ru_pro_arrange_block" от какого-нибудь "ru_pro_XXX_block"? не повторяется-ли там 90% кода - если так то может логичнее заменить на функцию с аргуметном, а не плодить "клонов" - хотя это только мои предположения.

[ShaggyDoc]

15000 команд c:xxx? - тут что-то не так с организацией команд - подумайте сами - слов в русском языке меньше, команды типа c:xxx предназначенны для непосредсвенного исполнения пользователем

А об этом пусть думают те, кто непременно оформляет свои программы в виде C:XXX. Я давным-давно понял, что это совершенно не нужно делать. Зачем нужна функция-команда?

1. Да они появились исторически, когда AutoCAD обладал минимальным интерфейсом и даже не всегда мышка была. Тогда чаще всего команды вводили с клавиатуры. Времена были такие, мерзопакостные. Вот и сделали возможность программистам создавать "команды".
Иногда действительно проще команду ввести с клавиатуры, чем лазить по многочисленным элементам интерфейса. Но имя должно быть простым и запоминающимся. Не "КРАНШАРОВЫЙБАБОЧКАШТУЦЕР-РЕЗЬБА_20" или наподобие. Вот и ввел цифровые имена. Легко запоминаются (те, которые надо), труднее ошибиться. И то только для тех, кому удобнее запомнить номер и вводить с клавиатуры. В общем-то удобно.

2. Последнюю выполненную "команду" можно повторить нажатием Enter. Тоже надо. Раньше все команды имели одно и то же имя - ради повтора. Оно было и невидимым (все равно не набирать), и в виде RU. Потом, как написал выше, сделал цифровые имена.

15000 - это не имен команд, и не пунктов в меню. Это полезных конечных действий. Да и то это я когда-то насчитал, сбился и плюнул. Теперь намного больше. Разумеется, нет никаких 15000 файлов. На сей момент их ровно 299. Это таких, в которых что-то индивидуальное. А большинство действий реализуется вызовом библиотечных функций с аргументами. Самые ходовые и оформлены в виде C:XXX. Я приводил пример:

Код:

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

 (defun C:4301 ()
  (ru-xml-pop-mnu  "3d/ru_3d_pipe_lines"  "Трассы трубопроводов")
  (princ)
)

Классический вызов библиотечной функции с двумя аргументами, только обернут именем 4301 ради быстрого вызова. Это как раз функция вызова иллюстрированного XML-меню, картинками которых я всех задолбал.

А вот уже в этом меню, в конечных листочках дерева, и сидят выховы функций с аргументами. Пункт такого меню выглядит наподобие

Код:

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

<item name="Катушка фланцевая 100-16" 
 image="3d\pipes\ru_3d_pipe_2_flange_rev.png" 
 comment="Прямой участок с фланцами на концах"
 macro="(ru-3d-pipe-draw-any (quote ru-3d-pipe-2-flange-draw-revolved) (ru-3d-pipe-flange-std-100-16) "Начало катушки" "Конец катушки" nil)" 
/>

Вот в атрибуте macro

Код:

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

 (ru-3d-pipe-draw-any (quote ru-3d-pipe-2-flange-draw-revolved) (ru-3d-pipe-flange-std-100-16) "Начало катушки" "Конец катушки" nil)

и записано LISP-выражение, с аргументами, да еще в качестве аргументов передаются имена других функций.

Например функция ru-3d-pipe-draw-any рисует "что угодно", имеющее начало и конец. В данном случае ей, с помощью функции quote передается имя функции ru-3d-pipe-2-flange-draw-revolved, рисующей в 3D фланцы приварные встык.

А если вызвать

Код:

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

 (ru-3d-pipe-draw-any (quote ru-3d-tee-muff) (list 48.0 33.5 100.0) "Вход среды" "Направление протока" 100.0)

то та же самая функция будет рисовать уже тройники муфтовые. Причем создавать такие пункты меню может и "смышленая тетка", безо всякого программирования. Что они и делают.

Впрочем, мы отвлеклись от темы ветки про "макросами кнопок"