[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

[gomer]

Сообщение от Salt в коде файла *.mnl определять, откуда же он загружается.

файл *.mnl загружается автоматически из той же папки, где лежит меню
зы ну и см. #9

[ShaggyDoc]

Есть и другая точка зрения: правильное приложение - это просто каталог с файлами. Скачиваете *.zip, распаковываете и готово. Без записей в реестре

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

Есть и точка зрения, что "мое приложение должно ставиться только в C:\SuperPuper". Такая точка зрения тоже быстро исправляется, когда жизнь мордой натычет.

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

Ответ на твою "проблему" давно дан (в том числе и в этой ветке) - своё положение приложение должно читать из реестра. Ветка в реестре этого приложения - единственное постоянное место. В древних программах под Win3 таким "постоянным" местом был INI-файл приложения, который непременно должен был лежать в каталоге Windows. Туда и сейчас особо "одаренные" программисты пишут, загаживая чужие компьютеры.

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

Но это уже определённая организационная дисциплина и совсем другая история...

А без организационной дисциплины в правильном программировании не обойтись. Это не "другая история", а основы правильной работы.

[Елпанов Евгений]

Полностью согласен с ShaggyDoc!

Мой очередной проект, должен был работать в фирме, в которой я появлялся всего пару раз на пять минут.
Внутри фирмы, нет CAD менеджера, только продвинутая начальница инженерно - проектного отдела.
Все составляющие программы упаковываются в один vlx для установки и пользователю вообще не важно как его запустить в акаде, достаточно из проводника перетащить на чертеж. Инсталятор для приличия спросит - вам полную установку или только меню, программные файлы поправить. Далее, программа устанавливается в заранее известную папку и подключается к базам на сервере.
Далее, при каждом запуске, программа мониторит папку на сервере, где могут лежать обновления и оттуда обновляет программные файлы по необходимости.

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

[Salt]

To Кулик Алексей.
Спасибо. Я совсем забыл про vla-методы!
Не имеющей решения остается единственная ситуация, когда лисп-приложение не имеет фрагментарного меню и, при этом, не лежит на путях поддержки.

To all
Я всегда считал, что чем проще, тем лучше. Если можно сделать без реестра, надо делать без реестра. Если можно без инсталлятора, делаем без инсталлятора. Ну не хочу я к приложению, состоящему из одного лисп файла и трех текстовых файлов, делать инсталлятор! Равно, как и нагружать неискушенного пользователя концепцией путей поддержки Я хочу, чтобы приложение легко было загрузить вручную и так же легко было, при желании, включить в состав другого приложения с помощью, например, единственной строчки (load...) в acaddoc.lsp. При этом не ковыряясь в файлах и не помогая приложению обнаружить самого себя.

[Елпанов Евгений]

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

[Salt]

To Елпанов Евгений

А как же:
vl-list-loaded-vlx
vl-list-exported-functions

[zamtmn]

Сообщение от ShaggyDoc Это точка зрения "юниоров", которые особо подчеркивают, что их "приложение" ничего в реестр не пишет. Да, можно и такие мелочи делать с простеньким функционалом. Ничтожным по сложности. Такая точка зрения быстро исправляется, когда жизнь мордой натычет.

Все кто не пишет в реестр еретики? А придется перенести приложение под брикс+линукс? фантастика конечно, но всеже... или бриксис уже эмулирует там реестр?
Чем это лучше хранения настроек в домашней папке пользователя?

[ShaggyDoc]

[quote=zamtmn;948731]Все кто не пишет в реестр еретики?
Не, не еретики. Просто непонимающие люди. Иначе бы и вопросы подобные этой ветке не возникали.

А придется перенести приложение под брикс+линукс? фантастика конечно, но всеже... или бриксис уже эмулирует там реестр?

Много здесь писателей под линукс? Но, если пишете под линукс, то надо придерживаться идеологии линукс. Конечно, там нет ресстра, но там есть другие средства, позволяющие программам однозначно определять положение своих компонентов.
Посмотрите, как хранят настройки кроссплатформенные программы. В любой OS есть своя система, которой надо придерживаться.

Чем это лучше хранения настроек в домашней папке пользователя?

Реестр - это постоянное место, а пользовательские папки - переменное.

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

Допустим, программу ставит Администратор. У него своя домашняя папка. И настройки программы, записанные туда, остальным пользователям не будут видны. Чтобы они становились доступны новым пользователям, опять же надо писать в реестр, причем в HKEY_USERS\.DEFAULT\Software. А это означает, что инсталляцию должен делать только Администратор.

Можно писать в папку AllUsers. Можно писать в HKEY_LOCAL_MACHINE\SOFTWARE. Но все это потребует тщательной проработки сценария инсталляции. Особо нужно учитывать блуждания Microsoft в части привилегий и разрешений. В WinXP было одно, в Vista другое, в Win7 - своё. Но, если программист учитывает требования Microsoft по написанию программ, они будут работать
всегда.

Например, если в XP "домашний" каталог это c:\Documents and Settings\UserName\Application Data\ а есть и c:\Documents and Settings\UserName\Local Settings\Application Data\, то в программе не должны быть зашиты эти имена. Потому что в другой OS уже нет никаких "c:\Documents and Settings\". А что именно должно быть - обязан выяснить инсталлятор.

Программа может быть и "самоинсталлирующейся", но это неудобно. Специализированные инсталляторы гораздо удобнее. В них просто в сценарии достаточно указать псевдоним, наподобие {localappdata} или {userappdata} или {commonappdata}.

Ну а ваша программа должна уметь эти данные прочитать.

[Salt]

Посмотрите, как хранят настройки кроссплатформенные программы.

Например .NET программы запросто хранят настройки в конфигурационных XML-файлах, располагаемых рядом с *.exe. И Микрософт именно так и рекомендует делать, если нет веских причин делать по другому. И я хочу, чтобы мое ничтожнейшее лисп-приложение подобным образом хранило настройки и всякую сопутствующую информацию возле себя и не пачкало реестр. И хватит уже об этом.

[zamtmn]

>>Не, не еретики. Просто непонимающие люди. Иначе бы и вопросы подобные этой ветке не возникали.
Отсутствие способа сделать это в программе на лиспе вовсе не значит что остальные ничего не понимают - ничего в знании пути к исполняемому файлу плохого нет.

>>Реестр - это постоянное место, а пользовательские папки - переменное.
при правильном обращении папки с файлами настройки ничуть не переменней реестра. Реестр конечно хорошо, но с ним абсолютно также можно работать "по юниорски", такчто не панацея.

[gomer]

Сообщение от ShaggyDoc все это потребует тщательной проработки сценария инсталляции

Да чего ж сложного? Всего то два сценария:
1. Распаковываем архив туда, куда и должны инсталлироваться программы, запускаем лисп-инсталятор, вуаля, все работает
2. Распаковываем архив куда глаза глядят, лисп-инсталятор, он злостно ругается, требуя сатисфакции, подсовываем ему файл меню, вуаля, все работает
>Salt, Большая разница? кто вам дохтор, что вы суете свои программулины куда ни попадя? можете хоть с флешки работать

Сообщение от zamtmn А придется перенести приложение под брикс+линукс?

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

[ShaggyDoc]

все работает

Ага. Только в присутствии "программиста".

[gomer]

Сообщение от ShaggyDoc Только в присутствии "программиста".

Думаю эта проблема несколько преувеличена, хотя конечно слеты случаются, но преимущественно не в акаде

[Елпанов Евгений]

Сообщение от Salt To Елпанов Евгений А как же: vl-list-loaded-vlx vl-list-exported-functions

эти функции ничего не дают взломщику моей программы!
(vl-list-loaded-vlx) - выдаст названия загруженных vlx, только названия.
(vl-list-exported-functions) - выдаст все экспортированные из всех языков функции.

Вопрос был простой - в моей программе загружено несколько vlx и невозможно узнать, откуда загружена текущая функция c:test.
Мне никто не запрещает ее для начала экспортировать из одного vlx потом из другого или из этой же, но переопределенной...

Ps. просто я использую механизм рекурсивной загрузки, в том числе для защиты...

[Salt]

1. Имена всех загруженных VLX-модулей с отдельными именными пространствами можно получить с помощью (vl-list-loaded-vlx).
2. (vl-list-exported-functions "ИмяVLXмодуля") выдаст все экспортированные функции из VLX-модуля с конкретным именем.

[Елпанов Евгений]

Salt, А ты хакер, однако!

[Salt]

Нет, я старый хрен (josser)

[gomer]

Сообщение от Salt выдаст все экспортированные функции из VLX-модуля с конкретным именем.

функция с именем f01698754 много о чем расскажет?

[Salt]

Спроси у хакеров на форуме хакеров