Jump to content

Настройки. Стандартные папки


Recommended Posts

Если в настройках->стандартные папки->общие файлы задать путь, то

у меня нано начинает по этому пути сохранять:

  • настройки принтеров *.pc3,
  • пихать в эту папку Last_Plot_Set_Layout.dwt и Last_Plot_Set_Model.dwt...

Собственно так задумано?

Цитата

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

В описании про поиск, про запись в эти каталоги ни слова

Link to comment
Share on other sites

12 минут назад, doctorraz сказал:

В описании про поиск, про запись в эти каталоги ни слова

 

Судя по всему, поиск (точнее, найденная папка) подразумевает, что именно в ней осуществляются все операции - чтение, запись и т.д..

Кстати, в АС это реализовано похожим образом.

Именно поэтому теперь при настройках папок эту секцию обхожу стороной.

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

Link to comment
Share on other sites

11 минут назад, EdwardSt сказал:

Кстати, в АС это реализовано похожим образом.

совсем непохожим)))

В АК это действительно папки поиска.. и допустим если я прописал в общие папки каталоги с лисп или exe файлами, то могу вызывать программы не прописывая полный путь, а лишь по имени файла, то же касается шрифтов, типов линий и прочего..

В любом случае АК принтеры, бумагу пишет в предназначенные для этого каталоги.

---------------

14 минут назад, EdwardSt сказал:

Именно поэтому теперь при настройках папок эту секцию обхожу стороной

аналогично, традиционно кривая нанореализация, к то му же пути поиска толком не работают

-----------

в нано21 аналогичная кривулина

добавлено через 1 минуту
16 минут назад, EdwardSt сказал:

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

лиспы и ехе куда прописывать? хотя смысла не имеет, нано все равно не ищет

Link to comment
Share on other sites

2 часа назад, doctorraz сказал:

совсем непохожим)))

В АК это действительно папки поиска..

Сейчас не готов в точности воспроизвести кейс...

Но только после того, как для такой универсальной папки закрыли доступ на запись для всех пользователей, только тогда в ней перестали появляться всякие артефакты типа Last_Plot_Set_L... и acad.lsp. Причем мусорил там именно АС. А нанокад до кучи туда еще извлекал какие-то рисунки из pdf или нечто подобное.

 

Короче, лучше просто заморочиться и для каждого типа операций прописать собственную папку. :D

Link to comment
Share on other sites

52 минуты назад, EdwardSt сказал:

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

в какую папку путь к этому

(startapp "PlotSPDS.exe")

и к этому

(load "bgtools\\bgtools 3.11a.lsp")

:shock:

Поудалял пути к общим папкам, иначе настройки принтера не сохранить)))

Где папки, а где принтеры.. nanoзатейники

Edited by doctorraz
Link to comment
Share on other sites

Подробно тему не разбирал. Но можно по пунктам

1 .

1 час назад, doctorraz сказал:

в какую папку путь к этому

(startapp "PlotSPDS.exe")

 

Спойлер

Signature

(startapp appcmd [file])

appcmd

Type: String

Application to execute. If appcmd does not include a full path name, startapp searches the directories in the PATH environment variable on Windows for the application and the equivalent on Mac OS.

Т.е., путь определяется операционной системой, а не CAD-приложением.

Более надежно прописывать имя файла с полным путем

 

2.

1 час назад, doctorraz сказал:

(load "bgtools\\bgtools 3.11a.lsp")

 

Спойлер

image.png.efe2bd64166b0481d10590114393e8ad.png

 

 

3

Спойлер

image.png.82c5efe643e31b5d47b0c7ae7bff7cbb.png

 

 

  • Like 1
Link to comment
Share on other sites

6 минут назад, EdwardSt сказал:

Более надежно прописывать имя файла с полным путем

в АК и без полного пути работает, достаточно имени файла с расширением (и путь поиска в каталоге)

в nano согласен, хождение по граблям

---------------

каталог скриптов только в нано21 появился,

только кто ж в нем  в трезвом уме и ясной памяти работу работать будет?

добавлено через 3 минут

вообще то это уже оффтоп лютый пошел, как обойти эти и другие nanoграбли я в курсе....

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

добавлено через 9 минут
11 минут назад, EdwardSt сказал:

Т.е., путь определяется операционной системой, а не CAD-приложением

а если взять и самому проверить?

справка это хорошо, но эксперимент лучше

в автокаде прописать в общих путь к своему экзешнику (каталог)

перезапустить АК

и (startapp "свой.exe")

 

даже такая конструкция без полного пути работает в АК

(defun C:поч ()
  (command "filedia" "0")
  (command "пакет" "PlotSPDS\\1.scr")
  (princ)
)

Edited by doctorraz
Link to comment
Share on other sites

15 минут назад, doctorraz сказал:

в АК и без полного пути работает, достаточно имени файла с расширением (и путь поиска в каталоге)

Ну, тогда справка по АС не соответствует реализации.

Там явно прописано, что приложение ищется в соответствии с переменной окружения Windows (PATH).

Если срабатывает и в папке общих файлов АС, то это недокументированная возможность (либо в PATH присутствует пресловутая папка).

Сам проверять ленюсь, поэтому с благодарностью принимаю результаты эксперимента.

 

19 минут назад, doctorraz сказал:

каталог скриптов только в нано21 появился,

только кто ж в нем  в трезвом уме и ясной памяти работу работать будет?

Тут, как бы не требуется использовать эту папку. 

Достаточно в эту секцию вбить собственную/ые (или корпоративную/ые) папку/и разработки.

Link to comment
Share on other sites

3 минуты назад, EdwardSt сказал:

Достаточно в эту секцию вбить собственную/ые (или корпоративную/ые) папку/и разработки.

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

достаточно загрузить основной лисп (автозагрузка)

остальные лиспы при необходимости прекрасно подгружаются по относительным путям (относительно стартового лиспа)

5 минут назад, EdwardSt сказал:

Сам проверять ленюсь, поэтому с благодарностью принимаю результаты эксперимента.

несколько лет использовал эту недокументированную возможность, пока на nano не пересадили(((

так, что верь на слово

добавлено через 2 минуты
6 минут назад, EdwardSt сказал:

Тут, как бы не требуется использовать эту папку. 

я и "папку" общие файлы не использовал, просто вбивал в эту секцию пути к "собственную/ые (или корпоративную/ые) папку/и разработки"

нано туда писать сразу начинает)))

Link to comment
Share on other sites

Кстате

2 часа назад, doctorraz сказал:

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

достаточно загрузить основной лисп (автозагрузка)

остальные лиспы при необходимости прекрасно подгружаются по относительным путям (относительно стартового лиспа)

АК так не может, проверил специально

Link to comment
Share on other sites

В принципе если научат nano искать и подгружать, ехе, ват и прочие  scr  по путям поиска из настроек, это будет мастхэв (кстате тот год уже обещали разобраться)

 И никакого дублирования команд..

Nana не умеет startapp

АК не умеет shell_exec

Edited by doctorraz
Link to comment
Share on other sites

15 часов назад, doctorraz сказал:

В принципе если научат nano искать и подгружать, ехе, ват и прочие  scr  по путям поиска из настроек, это будет мастхэв (кстате тот год уже обещали разобраться)

 И никакого дублирования команд..

Nana не умеет startapp

АК не умеет shell_exec

Добавила комментарий ваш в существующую задачу.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

  • 1 year later...
В 28.07.2021 в 12:00, yum сказал:

Добавила комментарий ваш в существующую задачу.

проверил ищет и находит по путям поиска

спасибо!

Link to comment
Share on other sites

следующая просьба

научите shell_exec относительные пути

по аналогии с load

поясню

загрузил лисп 

если рядом с загруженным лиспом есть каталог drRAZ, а в нем ЗАМЕНА.lsp 

то такая конструкция (из загруженного лиспа сработает)

(defun c:замена ();; замена чегото на другое 
  (load "drRAZ\\ЗАМЕНА")
  (princ)
)

и это круто!! независимо от путей поиска

-----------------

а вот shell_exec искать относительно  вызывающего лиспа не умеет, нужен полный путь или в путях поиска

реально что то сделать?

Link to comment
Share on other sites

21 минуту назад, doctorraz сказал:

следующая просьба

научите shell_exec относительные пути

по аналогии с load

поясню

загрузил лисп 

если рядом с загруженным лиспом есть каталог drRAZ, а в нем ЗАМЕНА.lsp 

то такая конструкция (из загруженного лиспа сработает)

ИМХО тогда уж лучше (если, конечно, это возможно) либо load дополнить, либо findfile'ом проверять существование lsp. В условиях nanoCAD, наверное, было бы лучше load дополнять:
 

(load "drRAZ\\ЗАМЕНА.lsp" "Файл ЗАМЕНА.lsp не найден")

 

  • Like 1
Link to comment
Share on other sites

С относительными путями для лиспов все хорошо

shell_exec аналог startup

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

Блин я load в пример привел, как надо(((

для shell_exec хочу относительные пути..

Ну или хотя бы каталог вызывающего лиспа

Link to comment
Share on other sites

6 часов назад, doctorraz сказал:

Ну или хотя бы каталог вызывающего лиспа

Ууууу, это ты загнул, каэшн... Особенно учитывая, что лисп (по крайней мере теоретически, сам я подобными извращениями не баловался) можно вообще на лету определять ;)

  • Like 1
Link to comment
Share on other sites

20 часов назад, kpblc сказал:

Ууууу, это ты загнул, каэшн

хех поразбирался немного тут...

для автокада нетривиальная задача, но..

нанокад в пути поиска включает и каталог в котором исполняется лисп (и это чертовски здорово!!!)

этот код в нанокаде вернет полный путь к исполняемому лиспу (tst.lsp) (хоть на луну помесить)

(defun tst (/fn aa)
(setq fn "tst.lsp")
	(if (findfile fn)
		(progn
			(setq aa (findfile fn))
			(prompt (strcat "\n" aa))
		)

		(prompt (strcat "\n" fn " not found\n\n"))
	)
	(princ)
)


(c:tst )

в автокаде если файл не в путях поиска не вернет ничего

---------------------------

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

это я и раньше знал, но мне нужно в моем приложении открывать файл справки (pdf, chm), лиспом кроме, как  shell_exec (shell) я не умею

но эта команда не умеет относительные пути, нужен полный

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

собственно корень поиска это лисп из которого вызываю функцию.. дальше просто с помощью  https://forum.dwg.ru/showpost.php?p=947705&postcount=9 и gomer

вот так получилось

; https://forum.dwg.ru/showpost.php?p=947705&postcount=9
; gomer
(defun drz_ShellFinder ( fn / ffn )
	(if (findfile fn)
		(progn
			(setq ffn (findfile fn))
			(command "shell_exec" (strcat "open," ffn))
		)
			(prompt (strcat "\nFile " fn " not found"))
	)
)

 

файл справки лежит в каталоге Resources

image.png.f95daec68e9288c5bee480d638f0079a.png

вызов

(drz_ShellFinder "Resources\\AutoFillHLP.pdf")

аналогично можно открывать другие файлы или запускать экзешники

 

tst.lsp

  • Like 2
Link to comment
Share on other sites

1 час назад, doctorraz сказал:

нанокад в пути поиска включает и каталог в котором исполняется лисп (и это чертовски здорово!!!)

Неожиданно.

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

Ну и насчет "здорово" - тоже не бесспорно.

Если писать лиспы, опираясь на этот казус, то они становятся менее универсальными по сравнению с АС.

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

И эти все каталоги попадают в пути поиска для новых подгрузок. 

Мешанина может получиться знатная, хотя последствия просчитать непросто. Может, и ничего страшного/

И остается неопределенность в случае, упомянутом @kpblc, когда лисповская команда будет формироваться в процессе работы приложения, а не загружаться командой (load ... или через автозагрузку.

Edited by EdwardSt
Link to comment
Share on other sites

Posted (edited)
55 минут назад, EdwardSt сказал:

эти все каталоги попадают в пути поиска для новых подгрузок. 

Не попадут

Добавляется только путь поиска от файла лиспа из которого вызвана команда

Проверить легко, загрузить лисп и попытаться выполнить  поиск его файла  из ком строки, не найдет, а из этого лиспа найдет

55 минут назад, EdwardSt сказал:

Если писать лиспы, опираясь на этот казус, то они становятся менее универсальными по сравнению с АС

Всежэж считаю это фичей..

 

В АК такое в принципе невозможно

Хотя если кто повторит в АК для большей универсальности.. Еще и по сети)))

 

Ну и при попытке выполнить лисп функцию с ошибкой нана напишет в каком файле, строку столбец

Автокад тоже эту информацию знает но не делится ей(((

В автокаде так сделать в принципе невозможно, выше ссылка на обсуждение, кончилось ничем

добавлено через 2 минуты

В нано лисп в контексте приложения работает, в ак контекст документа..

Т.е. в принципе многие лисп вещи в ак либо невозможны либо делаются с бубном

добавлено через 5 минут

В нано относительные пути, отдельная тема

Если через pakage загрузить библиотеку, то пути поиска будут не от dllки, а от pakage

Edited by doctorraz
Link to comment
Share on other sites

38 минут назад, EdwardSt сказал:

теоретически возможен случай

У меня так и грузится, из разных каталогов, по относительным путям

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

Если загрузить первый лисп по полному пути остальные из него можно грузить по относительным. В нк20 это уже работало, может раньше

Link to comment
Share on other sites

22 часа назад, doctorraz сказал:

Если загрузить первый лисп по полному пути остальные из него можно грузить по относительным.

А если нужно грузить несколько подобных "загрузчиков"? Откровенно говоря, лично я бы не надеялся на findfile & Co, и искал бы другие пути.

 

22 часа назад, doctorraz сказал:

в принципе многие лисп вещи в ак либо невозможны либо делаются с бубном

Верно и обратное :) В АС я с легкостью разделял через глобальные и "суперглобальные" переменные данные на каждый документ и не парился особо. В NC подобный фокус уже не прокатит )

22 часа назад, doctorraz сказал:

Если через pakage загрузить библиотеку, то пути поиска будут не от dllки, а от pakage

И кто и как будет знать, каким макаром загружен lsp? А откуда он запущен?

Не, мне как-то стремно делать ставку на такую технологию. По крайней мере пока :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Tell a friend

    Love Официальный форум компании Нанософт? Tell a friend!
×
×
  • Create New...