[SNIIP]

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

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

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