или искать например не acad.pat, который лежит и там и там, а например acad.cuix ?acad.cuix/acad.cui (в зависимости от версии AutoCAD) тоже не идеальный, но неплохой вариант. Тот который найдётся действительно будет лежать в доступном для записи каталоге (иначе нельзя редактировать конфигурацию). Найти его можно при помощи (getvar "menuname")
Для начала хватит?Хватит, спасибо.
"C:\\Users\\Rivilis-AN"Опять же проверил, все эти папки не содержат файлов, только папки, как то паливо туда файлы писать :-\
"C:\\Users\\Rivilis-AN\\AppData\\Local"
"C:\\Users\\Rivilis-AN\\AppData\\Roaming"
В общем, почти все мои приложения записывают маленькие вспомогательные файлики на компьютер пользователя, какие для записи настроек приложения, какие с записью регистрационных данных.Почему не хочешь для хранения своих вспомогательных файлов прописывать полный путь, вместо того, чтобы завязываться на расположение акадовских файлов? Например так: %AppData%\Geobuilder\<AppName>\tmp\.
Место для записи искал такКод - Auto/Visual Lisp [Выбрать]
все эти папки не содержат файлов, только папки, как то паливо туда файлы писать :-\А непосредственно в них файлы писать и не нужно. Создавай нужную тебе структуру подкаталогов и используй её по своему усмотрению. Принято в %AppData% (как и в %ProgramData%, %ProgramFiles%) подкаталоги формировать по правилу: %AppData%\<CompanyName>\<ApplicationName>\.
Почему не хочешь для хранения своих вспомогательных файлов прописывать полный путьНикогда не думал об этом, у кого-то давно в коде встретил, как вообще файлы создавать так и делал.
в каком случаи любая из этих системных переменных может быть nil, лишь в том случаи, если это относительно новая переменная и в ранних версиях AutoCAD её не было?Именно так. В ранних версиях этой переменной не было
Цитата: Александр Ривилис от 22-01-2016, 19:19:13У меня там есть и файлы.
"C:\\Users\\Rivilis-AN"
"C:\\Users\\Rivilis-AN\\AppData\\Local"
"C:\\Users\\Rivilis-AN\\AppData\\Roaming"
Опять же проверил, все эти папки не содержат файлов, только папки, как то паливо туда файлы писать :-\
Всё же файл с сохранением пользовательских настроек думаю стоит привязывать к конкретному AutoCAD-у.Ну так ты можешь, при желании разносить настройки по разным файлам в твоём каталоге, либо группировать их в рамках одного и того-же конфиг-файла.
А файл с регистрацией приложения, хотелось тоже писать более не заметно, чем создавать каталог <CompanyName>.Однако предложенная мною структура позволяет чётко определить, какой набор файлов не является "родным" для акада. На мой взгляд, хранить настройки плагинов и файлы, необходимые для их работы, целесообразней в своей структуре каталогов, не перемешивая их с "родными" файлами акада. Это облегчает и удаление их, если что-то пойдёт не так, да и позволяет более удобно это всё осматривать (не мозолят глаза лишние файлы акада - мухи отдельно от котлет).
Если в акадовский каталог будут писать файлы разные расширения от разных разработчиков, вместо того, чтобы распределять их по подкаталогам согласованной структуры, то этот каталог очень быстро превратится в помойку, в которой трудно будет разобраться.Согласен абсолютно.
не понятно, какие файлы в каталоге акадовские, а какие "левые" (чтобы удалить ненужный контент, закинутый кривым плагином).Всё, понял, не буду.
как я уже проверил Autolisp не понимаетНу так я же не lisp-код показывал, но само расположение каталога. :) Можно написать функцию, которая будет разворачивать имя переменной, присутствующей в составе пути, в её значение (дабы не использовать обозначенное тобою решение, которое нельзя "упрекнуть" в гибкости).Код - Auto/Visual Lisp [Выбрать]
только такКод - Auto/Visual Lisp [Выбрать]
будет разворачивать имя переменной, присутствующей в составе пути, в её значение
не переносимый локальный профильЯ пять раз прочитал, но всё равно не понял :o т.е. как бы вроде всё по-русски и о простом, и не самое важное, принципиальный ответ уже был выше...
Я пять раз прочитал, но всё равно не понялЕсть официальный термин в Microsoft Windows: "Перемещаемый профиль" (https://ru.wikipedia.org/wiki/%D0%9F%D0%B5%D1%80%D0%B5%D0%BC%D0%B5%D1%89%D0%B0%D0%B5%D0%BC%D1%8B%D0%B5_%D0%BF%D1%80%D0%BE%D1%84%D0%B8%D0%BB%D0%B8_%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D0%B5%D0%B9)
Я пять раз прочитал, но всё равно не понял :o т.е. как бы вроде всё по-русски и о простом, и не самое важное, принципиальный ответ уже был выше...На пальцах, говоришь... Попробую.
Мне очень нравятся ответы Горлова Николая, они и улыбку вызывают стилем написания и понятно всё как на пальцах :D
как бы вроде всё по-русски и о простом, и не самое важное, принципиальный ответ уже был выше...Ну как сказать... Понимать то, куда какую информацию лучше записывать, учитывая специфику переносимого и непереносимого профиля - это не так уж и "не самое важное". ИМХО.
Папка, в которой лежал LISP, при установке прописывалась в путь поддержкиЕсли под каждый LISP добавлять каталог поиска, то Support File Search Path достаточно быстро превратится в помойку. Тынц (http://bushman-andrey.blogspot.ru/2012/03/autocad.html).
Но тут проблема в том, что этот механизм придется самим разрабатывать и поддерживать. Если бы это каким-то образом было бы внедрено в AutoCAD самим Autodesk'ом, то могло бы стать хорошим стандартом для всех разработчиков.Какой ещё "механизм"? Чего "поддерживать"? Если говорить о AutoCAD новее чем 2011, то каталоги для размещения bundle-пакетов определены - размещаешь там свои приложения в соответствии с правилами, обозначенными Автодеском в документации (банальный копипаст). Чем не устроил "новый" механизм загрузки от Автодеска? Если говорить о более ранних версиях AutoCAD, то и тут проблем нет - юзер или админ принимает решение о том, в каком каталоге будет хранить все плагины акада и добавляет этот каталог в пути поиска. Затем просто копирует каталоги пользовательских плагинов в этот каталог. Всё. Какой тут "механизм" нужен? Чего там требуется "поддерживать"?
А пока реальность такова, что да, каждое более-менее серьезное приложение добавляет как минимум один путь в SupportPaths. Я говорю не об отдельном LISP файле, а именно о законченном приложении, которое может состоять как из одного, так и из нескольких LSP/DCL/DLL и вспомогательных файлов."Серьёзные" приложения относятся к вопросу своего размещения и конфигурирования серьёзно и предоставляют тому, кто устанавливает приложение, указать каталог его размещения. Если указан один из каталогов, присутствующих в каталогах поддержки, то "серьёзному" приложению нет нужды писать дополнительную запись в каталоги поиска, при условии, что оно оперирует относительными путями (т.е. нормально продумано). Если юзер указал иной каталог установки, то тогда этот каталог возможно будет целесообразным добавить в каталоги поиска (но это одна запись, а не отдельная под каждый чих).
Если использовать тот механизм, который предлагает Autodesk - Bundle-пакет, то я пока не могу представить, как можно сделать по другому.Этой фразы я не понял. Т.е. ты не представляешь, как для Bundle-пакета можно обойтись без добавления новой записи в Support Files Search Path? В документации чётко прописан порядок поиска ресурсов новым механизмом, обрабатывающим такие плагины.
Я когда на LISP приложения писал, регистрационные данные в реестре хранил. Там же у меня были какие-то настройки, если для их хранения достаточно было одной переменной - строка, число и т.п. Хранил в HKCU/Software/<Мой раздел>/<Подразделы>. Это в качестве альтернативы.Ни когда с реестром не работал, функции для этого знаю, но опыта не было. Да и полного понимания что такое реестр нет.
Есть какие-нибудь нюансы, ну типа куда писать нельзя, что писать нельзя, и как всё это может пропасть?Безопасность реализована так же как в файловой системе - посредством ACL (https://ru.wikipedia.org/wiki/ACL).
Весьма удобно работать.Да, спасибо, уже почитал http://autolisp.ru/2011/04/11/data-set-and-get-03-2/