[SNIIP]

Подскажите Lisp функцию аналог дельфийской Application.exename

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

http://forum.dwg.ru/showthread.php?t=78208

[SNIIP]

Сразу после того, как ты загрузишь lsp/fas/mnl в AutoCAD, связь с файлом исчезает. В дальнейшем, при запуске команд, предварительно загруженных из файла, обращение к нему (файлу) не происходит, поскольку команды уже находятся в памяти.

Это означает что никак не узнать то, откуда был загружен лисп файл? или я не так понял?

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

Можно только средствами ObjectARX, насколько я помню из общения с А.Ривилисом.

[ShaggyDoc]

Это означает что никак не узнать то, откуда был загружен лисп файл

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

[hwd]

Я считаю, что это "косяк" автодеска. Не составляло никакого труда создать событие, предшествующее загрузке библиотеки, в котором аргумент, помимо прочего, имел бы свойства FileFullName и Cancel. Первое - содержит полное имя загружаемого файла, второе - логическое значение, указывающее следует ли отменить загрузку.

[ShaggyDoc]

Сообщение от hwd Я считаю, что это "косяк" автодеска. Не составляло никакого труда создать событие, предшествующее загрузке библиотеки, в котором аргумент, помимо прочего, имел бы свойства FileFullName и Cancel. Первое - содержит полное имя загружаемого файла, второе - логическое значение, указывающее следует ли отменить загрузку.

Ты хоть отвлекись от своей .Net, Windows и событийной модели. Посмотри аргументы Lisp-функции load. Там и FullName есть и второй аргумент. И при системном подходе всегда известно, откуда функция загружена. А при бессистемном, легко в теле функции ввести соответствующую глобальную (о, ужас) переменную.

Вот чего действительно не хватает в объектной модели AutoCAD, так это методов наподобие LoadLisp и RunLisp.
LoadARX - есть, LoadDVB -есть, даже LoadShapeFile есть для любителей археологии. И просто Load есть (для типов линий и меню). А вот LoadLisp - нет.

Объясняю это исключительно происками "сионистов" и примкнувших к ним майкрософтчиков. Слишком тогда просто было бы многое решать, безо всяких SendCommand.

А события есть: BeginLISP(FirstLine), EndLISP, LISPCancelled(). Толку-то от них.

[hwd]

Сообщение от ShaggyDoc Ты хоть отвлекись от своей .Net, Windows и событийной модели. Посмотри аргументы Lisp-функции load. Там и FullName есть и второй аргумент.

Мне нет нужды "отвлекаться" на лисповые функции. Имхо - использование SendCommand для загрузки лиспов в .нет плагинах - "слабое звено" объектной модели автокада.

Сообщение от ShaggyDoc И при системном подходе всегда известно, откуда функция загружена. А при бессистемном, легко в теле функции ввести соответствующую глобальную (о, ужас) переменную.

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

Вот чего действительно не хватает в объектной модели AutoCAD, так это методов наподобие LoadLisp и RunLisp. LoadARX - есть, LoadDVB -есть, даже LoadShapeFile есть для любителей археологии. И просто Load есть (для типов линий и меню). А вот LoadLisp - нет.

+1

Сообщение от ShaggyDoc А события есть: BeginLISP(FirstLine), EndLISP, LISPCancelled(). Толку-то от них.

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

[gomer]

Сообщение от hwd Мне нет нужды "отвлекаться" на лисповые функции

вот и не отвлекайтесь, пишите на сишарпе и be happy... Вот, хотел написать, что перевести лисп программу среднего уровня, это не так уж сложно, но... при всем уважении к новым технологиям, все они (а это по сути си++ а ля аркс, сишарп и барсик) по простоте написания кода и в подметки лиспу не годятся (тут вот многие энтузиасты для солидности лямбды пользуют, а вы пока модель для записи не откроете и нарисовать ниче не могете)
Да все можно, главное знать, чего хочешь-то. Имя файла из которого загружена функция не гарантирует ничего, поэтому и нет возможности отследить ее происхождение, как и нет возможности ее выгрузить, да это по сути и не нужно... а что нужно? загрузить менюшку? найти блок? так есть findfile, getfiled, vl-registry-read и vl-catch-all-apply
например так вот:

Код:

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

 (defun SuperLoadLisp (fn / catch shortn)
  (vl-load-com)
  (if (findfile fn)
    (progn
      (prompt
        (strcat
          "\nLoading "
          (setq
            shortn
            (strcat
              (vl-filename-base fn)
              (vl-filename-extension fn)
            )
          )
          " from "
          (vl-filename-directory fn)
        )
      )
      (if
        (vl-catch-all-error-p
          (setq catch (vl-catch-all-apply (function load) (list fn)))
        )
        (prompt
          (strcat
            "\nError loading "
            shortn
            ": "
            (vl-catch-all-error-message catch)
          )
        )
        catch
      )
    )
    (prompt (strcat "\nFile " fn " not found"))
  )
)

хотя так вот короче

Код:

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

 (defun SuperLoadLispClassic ( fn / *error* short )
  (defun *error* (msg)
    (prompt (strcat "\nError loading " short ": " msg))
  )
  (if (findfile fn)
    (progn
      (prompt
        (strcat
          "\nLoading "
          (setq
            short
            (strcat (vl-filename-base fn) (vl-filename-extension fn))
          )
          " from "
          (vl-filename-directory fn))
       )
      (load fn)
    )
    (prompt (strcat "\nFile " fn " not found"))
  )
)

[ShaggyDoc]

Мне нет нужды "отвлекаться" на лисповые функции.

Ага, и "я не буду глотать столько попугаев" (С). Поэтому написанное далее - для тех, у кого есть нужда.

Я бы не стал называть загрузку лиспов из автокадовских каталогов поиска "системной" загрузкой

А я разве называю? Я писал не о "системной загрузке", а о системном подходе. А при таком подходе в автокадовские каталоги абсолютно ничего нештатного не должно помещаться. Каждому приложению - свой профиль, с папками вне Автокада. Чтобы в любой версии можно было использовать.
И загрузка функций без помощи findfile, а с передачей полного вычисляемого имени.

И при системном подходе уже по имени функции известно, где она проживает и откуда загрузилась.

Для примера - имя ru-3d-steel-erico-bracket-2-channel-draw однозначно говорит, где эта функция находится. Помимо НеЗнаюЗачемНоКому-тоНужного программного определения её местоположения, такое имя легко позволяет найти и вручную среди тысяч подобных.

[Дима_]

Если смотреть чуть пошире (на Автолисп как на лисп) - то понятно что не может в принципе быть функции определяющей "свое" местоположение. Может быть "частный случай" который иногда будет работать правильно. Добавим сюда еще что в автолиспе динамическая типизация и как понятие отсутствует именные пространства (окружения - не путать с Net'овскими "определителями активных библиотек"). Про програмно сгенерированные функции я вобще молчу (хотя люба функция имеющая хотя-бы 1 аргумент, по сути перед каждым eval'ом - то есть при каждом выполнении ГЕНЕРИРУТЬСЯ заново, и совсем не факт что внесет больше изменений в нее загруженный "скелет", чем аргумент который может быть получен откуда угодно).
з.ы. Кто не понял про что написанно, но интересно - изучите суть функций READ, EVAL/APPLY - у них во всех лиспах суть одинаковая.

[ShaggyDoc]

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

Совершенно верно. Но "частный случай" можно сделать так, чтобы он для разрабатываемой тобой функции возвращал правильный результат. Можно также сделать обертку для штатной функции load, чтобы получать полный путь в результате загрузки. Наподобие:

Код:

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

 (defun _ru-app-load-lsp (name ext / lsp result)
    (setq lsp (strcat (ru-file-app name) ext))
    (if (findfile lsp)
      (if(equal (load lsp "Failed") "Failed")
         (princ(strcat "\nПрограмма \n" lsp "\nне может быть загружена! Возможно она испорчена!"))
         (setq result lsp)))
    result
) 

Ведь любая программа запускается не "сама по себе". Её кто-то (что-то) запускает. И этот "некто" знает, где лежит программа.

аналог дельфийской Application.exename

Дельфийская программа тоже не знает, где она проживает. Она выясняет это у Application.exename. А это фактически обертка для ParamStr(0), просто для человека понятнее. А что содержится в ParamStr(0) знает операционная система, т.е. среда, запустившая программу. Именно к ней, к проклятой OS, и переадресуется запрос в конечном итоге.

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

Автодеску не потребовалось бы много усилий на их добавление - просто, видимо, желания нет (возможно в основу положены какие-то соображения).

Да какие уж соображения - просто "они ж тупые" (С). И "вредители" есть, само собой.

PS. Весьма подробно варианты загрузки реализованы в библиотеке Reini Urban STDLIB.
А уж для любителей apply,eval, read и прочих мапкаров это вообще "просто праздник какой-то".
Жалко, давно работа заброшена.

[hwd]

Сообщение от ShaggyDoc просто "они ж тупые" (С)

-1.

[Salt]

Ведь любая программа запускается не "сама по себе". Её кто-то (что-то) запускает. И этот "некто" знает, где лежит программа.

Но ведь бывают ситуации, когда некое лисп-приложение помимо собственно файлов *.lsp(fas,vlx) содержит в своем составе некоторое количество файлов поддержки (скажем, текстовых), которые развертываются в том же корневом каталоге, что и основной программный файл, или даже в иерархии подчиненных каталогов. В этом случае коду основной программы известны относительные пути к файлам поддержки, но кроме этого совершенно необходимо знать и абсолютный путь к самому себе. Понятно, что если разместить приложение на путях поддержки, то зная имя головного программного файла, findfile легко справится с этой задачей. Но удобнее было бы обходиться без использования путей поддержки. Вы поставляете самодостаточное лисп приложение, для работы котрого совершенно неважно, где пользователь его разместит. Понятно, что это не всегда возможно, но в ситуациях, когда это возможно именно так и хотелось бы поступать. Но увы.

[gomer]

Сообщение от Salt увы

Добавляете в пути поддержки вашу папку или читаете ее из реестра и не паритесь, че сложного то?

[ShaggyDoc]

Вы поставляете самодостаточное лисп приложение, для работы котрого совершенно неважно, где пользователь его разместит. Понятно, что это не всегда возможно

Это всегда возможно при условии правильного создания приложения. А создание приложения - это не просто написание кода на любом языке. У правильного приложения должен быть инсталлятор, который, при установке, спросит - куда поставить. И ставить должен ни в коем случае не в папки Автокада, а куда положено по идеологии Windows.

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

А правильное приложение знает этот ключ, читает его, узнает и свой адрес, и адреса любых своих компонентов. Никаких путей доступа Автокада тут и не требуется использовать. Единственно, если захотите сделать автозапуск своего приложения, то можно сгенерировать инсталлятором acaddoc.lsp. Вот этот файл и нужно загружать через findfile. Но тогда надо сделать профиль своего приложения и помещать свой acaddoc.lsp в путь поиска этого профиля. Чтобы не мешать никаким другим приложения.

[Salt]

У правильного приложения должен быть инсталлятор,...

Есть и другая точка зрения: правильное приложение - это просто каталог с файлами. Скачиваете *.zip, распаковываете и готово. Без записей в реестре.
Интеграция с автокадом происходит через файл фрагментарного меню и штатную команду MENULOAD. На роль головного файла ("паровоза") такого лисп-приложения прекрасно подходит файл *.mnl. Вот при таком сценарии развертывания и актуален вопрос, обсуждаемый в данной ветке, т.е. в коде файла *.mnl определять, откуда же он загружается. ИМХО.

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

При таком сценарии достаточно определить имя файла меню. Там же и будет лежать mnl.

[Salt]

Что значит "определить имя файла меню"? Я - разработчик приложения и, естественно, знаю имя файла фрагментарного меню. Вопрос, как определить полный путь к этому файлу из кода файла *.mnl, например, если он не лежит на путях поддержки?
Можно и по другому сформулировать проблему: я хочу чтобы мое приложение можно было загружать "вручную" командой APPLOAD и оно работало вне зависимости от того, откуда загружено.

p.s.
Любой лисп-файл кто-то загружает, т.е. всегда существует некий "менеджер-загрузчик", который знает, откуда и что берется. Этот менеджер может предлагать служебную функцию, возвращающую полный путь к любому загруженному им же лисп-файлу. Останется этой функцией воспользоваться в коде. Но это уже определённая организационная дисциплина и совсем другая история...

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

Что значит "определить имя файла меню"?

Посмотри на результат выполнения:

Код:

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

 (vl-load-com)

(defun test (/ res)
  (vlax-for item (vla-get-menugroups (vlax-get-acad-object))
    (setq res (cons (cons (vla-get-name item) (vla-get-menufilename item)) res))
    ) ;_ end of vlax-for
  (vl-sort
    res
    '(lambda (a b)
       (< (strcase (car a)) (strcase (car b)))
       ) ;_ end of lambda
    ) ;_ end of vl-sort
  ) ;_ end of defun