> В. Свет
Так я и не скрываю - книга написана очень доходчиво, она закрывает собою ту нишу, которую никак не может заполнить BHV - для начинающих, которые очень мало знают (если вообще хоть что-то знают). Без нее понимание тонкостей када ко мне ну никак не приходило.
По профилям: фактически в реестре (HKEY_CURRENT_USER\Software\Autodesk\AutoCAD LT\R10\ACLT-301:419\Profiles - это для LT 2005 Rus, для английской версии LT 2005 будет HKEY_CURRENT_USER\Software\Autodesk\AutoCAD LT\R10\ACLT-301:409\Profiles) хранятся настройки нескольких профилей. В принципе, некоторые сторонние приложения открывают эту заглушку и позволяют в LT работать с несколькими профилями. По идее к ним можно попытаться обратиться (но тут есть одна тонкость - вчера проверил: в LT 2005 мне не удалось заставить запускаться кад с ключом \p в ярлыке, т.е. надо извращаться). 2006-го нет, к сожалению, так что как там организовано, могу только догадываться.
...По поводу (_) или (_.) перед именем команды в локализ. версии...
Да нет, локализация команды не есть ее переопределение. Фактически это индентично, если бы я написал лиспик:
(defun c:add-line()
(command "_.-Layer" "_Make" "Lines" "")
(command "_.line")
(while (and
(/= (getvar "cmdactive") 0)
(/= (getvar "cmdnames") "")
)
(command pause)
)
)И потом из acad.pgp по алиасу L вызывал бы не LINE, а ADD-LINE. Вот и все переопределение имхо.
Да все дело в том, что если где-то в глубинах навешанных лиспов стоит нечто типа такого:
(defun c:LINE()
(princ "\n Переопределенная команда!")
(Функция_номер_164_для_чего-нибудь)
)
и где-то в стартере (например, в acaddoc.lsp) есть команда
(command "_.undefine" "line")
, то после инициализации лиспов по команде LINE, _LINE будет работать именно переопределенная команда, а вот _.LINE вызовет стандартное приглашение к указанию точки и построению отрезков.
По поводу сокращений и "_". Просто у меня стиль стал такой (показалось наиболее удобным): все значения системных перемнных, с которыми я работаю, хранить в переменных с именами этих системных переменных, желательно полных, возможно, с небольшими сокращениями. Т.е. значение "cmdecho" хранить в _cmdecho_; "orthomode" - в _orthomode_ (возможно, _ortho_); "nomutt" - в _nomutt_ ну и так далее. Второй символ подчеркивания практически гарантирует, что имя переменной не будет опознано кадом как команда и если случайно попадет в ком.строку, то просто вызовет ошибку, а не труднопонимаемую последовательность действий. Собственные правила я где-то на dwg.ru описывал (точно тему не помню)
Обнуление переменных... Как бы сказать-то (ну не писатель я, не писатель). Ну, в общем, тут дело такое - переменная кушает какое-то количество памяти, что само по себе не есть гуд - памяти, как и денег, много не бывает. Кроме того, обнуление переменных гарантирует, что никаким образом даже случайно не будет использовано сохраненное там значение (если там nil, то тогда попытка сделать нечто типа (setvar "snapunit" nil) выдаст ошибку - а не попытку поставить на системную переменную значение с координатами точки.
Если переменная должна храниться всю сессию када, то тогда, конечно, ее надо не обнулять. Но тогда постоянно придется проверять ее на заполненность - в лиспе-то это решается на ура, а вот с макросами... ИМХО будет невероятное удлинение макросов. К примеру:
Есть некая переменная *vova* (поскольку она глобальная, "обрамим ее символом *, благо кад в этом отношении очень терпим). Хранит эта переменная значение масштаба. Масштаб устанавливается отдельной кнопкой, на которой висит макрос вида (для установки масштаба 1:100):
А потом идет простановка размеров:
Было
Станет:
^C^C(setq _dimscale_ (getvar "dimscale"));(setvar "dimscale" *vova*);
_.dimlinear;\\\
(setvar "dimscale" _dimscale_);(setq _dimscale_ nil);
Лишние переводы строк удалить.
А если изначально (для данной ситуации) не было установлено значение *vova*, макрос работать не будет. Придется в начало вколачивать проверку *vova* на nil, если *vova* не установлено, то либо выдавать соответствующее предупреждение, либо устанавливать переменную в значение "по умолчанию" (которое практически гарантированно породит дополнительные проблемы) ну и так далее.
Отследить, что где и как работает, будет очень трудно. Я столкнулся и с этим, и с тем, что абсолютно одинаковые действия приходилось множить... Пришлось садиться на лисп, делать автозагрузчик лиспов, и переделывать меню.
Но это лично моя история,
> Влапдимир Громов
Интересный ник однако ;) Но суть не в этом. Именно неопытные пользователи могут (и, самое страшное, делают!) ставят лиспы, которые написаны неизвестно кем и неизвестно как. Там и не такое встречается - для ради эксперименту там только что не выполняется переопределение настроек активного профиля (хотя и такое может быть). Опытные по крайней мере делают отдельный профиль, на котором и тестируют все приходящие программки и программульки, а также анализируют код.
---
P.S. Надеюсь, не очень сумбурно?
---
P.P.S. Всю дорогу - IMHO, IMHO, IMHO...
