[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; ?
Есть ли противопоказания у такого подхода ?

[gomer]

просто не используйте одинаковые имена функций...
при современных объемах ОЗУ лучше подгружать все скопом в файле mnl так ваше меню станет намного легче...

[swkx]

Сообщение от gomer просто не используйте одинаковые имена функций...

Не думаю, что это хорошая идея.
Описанный случай из практики. Заказчик попросил некоторую функцию. Я ему её предоставил. Примерно через месяц потребовалась ещё одна, похожая на первую, но несколько видоизменённая. Проще было её реализовать на базе первой. Разумеется, все имена внутренних функций остались прежними, только с другим наполнением.

А если прошел год, два, а не месяц ? Всё ведь не упомнишь...

У любого программиста есть сотни функций, кочующих из программы в программу иногда без изменений, иногда с незначительными правками.
Предлагаете всем им давать уникальные имена ?

[gomer]

Сообщение от swkx Разумеется, все имена внутренних функций остались прежними, только с другим наполнением.

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

Сообщение от swkx А если прошел год, два, а не месяц ? Всё ведь не упомнишь...

вот поэтому

Сообщение от gomer просто не используйте одинаковые имена функций...

[VVA]

Сообщение от swkx У любого программиста есть сотни функций, кочующих из программы в программу иногда без изменений, иногда с незначительными правками

Это называется библиотека функций и имена у низкоуровненных функций не меняются. Объемы современны ОЗУ позволяют сильно не задумываться об оптимизации кода. Если не имеешь своей библиотеки, то можно функции объявлять локальными (т.е внутри функций). В таком случае время их жизни - время работы самой верхней ф-ции.

Код:

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

 
(defun c:test1 ()
    (defun func-alert ()
	    (alert "Test 1")
		  )
(func-alert)
 )

(defun c:test2 ()
    (defun func-alert ()
	    (alert "Test 2")
		  )
(func-alert)
 )

[Li6-D]

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

[swkx]

VVA и Li6-D,

Локальные функции это, конечно, хорошо. Но как быть с уже написанной уймой программ без этих самых локальных функций ?

Повторю вопрос: есть ли подводные камни у способа вызова команды без проверки её предварительной загрузки, т.е.
^C^C(load "C:\\test1.lsp");test1; ?

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

Теоретически есть - через atom-family (кажется, так) проверяешь существующие имена функций и переменных. Но намного проще и быстрее писать нормальный код, с использованием нормальных локальных переменных и функций.

[swkx]

Сообщение от Кулик Алексей aka kpblc Но намного проще и быстрее писать нормальный код, с использованием нормальных локальных переменных и функций.

Конечно так лучше, но ведь на момент написания твой собственный код кажется тебе самым лучшим, а то, что он не такой уж и нормальный, выясняется уже потом)))

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

Сообщение от swkx Конечно так лучше, но ведь на момент написания твой собственный код кажется тебе самым лучшим, а то, что он не такой уж и нормальный, выясняется уже потом)))

Достаточно просто думать "а как я буду с ним разбираться через полгода-год" "САПР на баз AUtoCAD - как это делается". Настоятельно рекомендую. Дополнительно: http://autolisp.ru/2009/09/12/code-formatting/

[swkx]

Сообщение от Кулик Алексей aka kpblc Достаточно просто думать "а как я буду с ним разбираться через полгода-год"

Со своим кодом разобраться всегда можно, но ведь вполне возможна и следующая вполне типичная ситуация:
обычный продвинутый инженер-проектировщик обращается к кому-нибудь с просьбой написать программу, получает её, самостоятельно вешает её на кнопку и наслаждается жизнью. Через некоторое время обращается к другому программисту с очередным заданием, проделывает то же самое и наслаждается до тех пор, пока не нарвётся на описанную выше хрень.
А вероятность того, что в двух программах разных авторов окажутся НЕ локальные функции с одинаковыми именами, довольно высока. Например, вывод в Excel (toexcel), создания диалога "на лету" (make-dialog), перевода углов в радианы (dtor) и т.п. и т.п.

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

Сообщение от swkx А вероятность того, что в двух программах разных авторов окажутся НЕ локальные функции с одинаковыми именами, довольно высока

Зависит от автора

Сообщение от swkx вывод в Excel

_kpblc-datas-export-to-excel

Сообщение от swkx создания диалога "на лету"

fun_make-dlg, и ее в локальные

Сообщение от swkx перевода углов в радианы

_kpblc-conv-degrees-to-radians или _kpblc-angle-convert. Попробуй найти еще подобные имена.
Еще раз говорю - внешняя команда, которую и вызывает пользователь, может иметь любое имя. Все остальное - потроха, про само существование которых пользователь зать не должен.

[swkx]

Алексей,

а причем тут твои функции ? Не все же ими пользуются. Рискну даже предположить, что не все заглядывают на этот форум, хотя это и трудно себе представить)))). Я говорю про двух разных программистов, программы которых окажутся у одного пользователя, который действительно не должен ничего знать про внутренности. И вот в этих двух программах вполне могут оказаться одноименные функции.
И для этого самого пользователя вызов команды ^C^C(load "C:\\test1.lsp");test1; - единственный надежный выход из положения.

[Li6-D]

Если после (load "C:\\test1.lsp") ввести (load "C:\\test2.lsp"), то все глобальные переменные (включая функции), определенные в файле C:\test1.lsp будут заменены новыми из C:\test2.lsp при совпадении имен.
Тут ничего не поделаешь. Культурный программист постарается не использовать
глобальные переменные-функции или даст им уникальные имена
Например, Алексей добавляет префикс _kpblc.

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

swkx, а я говорил про принципы именования функций и ни про что иное. Формируешь свой принцип и строго ему следуешь. Вот и все...

[swkx]

Li6-D и kpblc,

вы правы, до меня сразу не дошло, о чем говорил Алексей.
Однако это принципы, которыми нужно руководствоваться при написании будущих программ. Учту.
Хотя изначально речь шла о выходе из положения при уже свершившемся факте.

[Лиспер]

А кто-то мешает прямо сейчас переделать пару кодов? Ну или сделать примерно так, как описано в http://autolisp.ru/2009/10/21/lisp-overloading/ ?

[E-degtyarev]

swhx, Загружаю Lisp-ы именно так, как ты предлагаешь (без IF) начиная где-то с 1997года. Никаких проблем не возникало, хотя теоретически их можно придумать. До 1997 года работал на машине АТ286 с "куриными мозгами" (хотя тогда это было круто). Там даже приходилось делать оверлеи и подгружать их. А современная машина несколько десятков килобайт lisp-a проглатывает не жуя. При этом не чихает и не кашляет. ИМХО.

PS: С точки зрения профессионала это конечно тупо, но я Lisp-любитель, кустарь-одиночка, и все себе заранее прощаю.

[swkx]

Сообщение от Лиспер А кто-то мешает прямо сейчас переделать пару кодов?

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

E-degtyarev,
я это и хотел услышать ))
Кстати, мне тоже приходилось использовать собственные лиспы на 286-м компе и 9-м автокаде. Выручала только функция (gc).

[gomer]

swkx, у вас все лиспы находятся в корне диска с:? а если я захочу установить на другой диск? На каком-нибудь 10 уровне вглубь... как будет меню выглядеть?
как-то сделал функцию загрузки и запуска команды:

Код:

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

 (defun cdl-run (cmd fil / tmp)
;;; функция загруски и запуска команд
;;; (cdl-run 'ALIST "ALIST.LSP")
  (if (not (boundp (read (setq tmp (strcat "c:" (vl-princ-to-string cmd))))))
	  (progn (if *cdl_nomute* (prompt "\nЗагрузка..."))(load (findfile fil)))
  )
  (eval (read (strcat "(" tmp ")")))
)

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

[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)

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

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