Преобразование единиц измерения блоков в файле
Известно, что при создании блока (ручного создания) можно указывать единицы, в которых этот блок будет вставляться: миллиметры, метры, дюймы и т.д. Это удобно, если гарантируется, что вся работа всегда выполняется на основе единственного шаблона с раз и навсегда настроенными единицами. Но бывает такое не всегда (да и за смежниками, бывает, приходится "доделывать").
Оптимальным решением, как ни странно, будут "безразмерные" блоки. То есть те, у которых единицы - "Unitless" (в русской версии перевода не помню). С новыми блоками все понятно - достаточно контролировать это значение и стараться не допускать ошибок. А что делать со старыми, уже вставленными? Да очень просто - заменить!
Далее
Выполнение кода сразу после загрузки .NET-dll
Иногда бывает необходимо до вызова команд (а еще лучше - прямо после загрузки кода) выполнить некоторые действия: установить системные переменные, установить пути поддержки и т.п.). В лиспе это просто:
1 2 3 4 5 6 | (defun test() (alert "test") ) ;; А вот и выполнение (test) |
Это то, что в лиспе часто называют "самовызовом". Выполнение кода начинается сразу после загрузки соответствующего lsp-файла в память.
Механизм достаточно удобный, несмотря на некоторые трудности, описанные здесь и здесь.
С .NET ситуация немного иная.
О кодах, загрузке и компиляции. Часть 2.
Продолжим начатое здесь.
Загрузка lsp сама по себе, конечно, интересна, но... Но быстродействие скомпилированного fas'a может быть в несколько раз выше. Разберем компиляцию сборника lsp в единый fas-файл.
Далее
О кодах, загрузке и компиляции.
Почти худлит получится, я думаю. Но тем не менее, поделиться хочется.
Разговор будет о том, как хранить созданные коды, как их загружать и компилировать. Естественно, что все написанное - сугубо личное мнение, и работать во всех условиях не будет. Но, может быть, кому-то и пригодится. Поехали?
Далее
Создание табличного стиля
В предыдущих частях вроде бы разобрались с созданием и модификацией текстового и размерного стилей. Так сказать, прочувствовали, что создание и изменение текстового стиля проработано просто превосходно (оба варианта - и entmake, и vla - отрабатывают просто отлично); что размерный стиль можно создавать только через entmake (если, конечно, вести разговор именно о LISP'e). Сегодня разберемся с табличными стилями.
Далее
Создание размерного стиля
В предыдущей части был рассмотрен вариант создания текстового стиля. Там все достаточно просто и универсально: хоть через entmake, хоть через ActiveX: как хочешь, так и создавай. С размерным стилем ситуация немного иная...
Далее
О создании стилей в dwg
Как известно, в файле dwg есть такое понятие, как стили (текстовый; размерный; мультилинии; начиная с версии 2005 вводится понятие стиля таблиц). Об их создании сейчас и поговорим.
Далее
О параметрах вызова и “перегрузке” lisp-функций
Известно, что в "нормальных" языках программирования (таких, как Visual Basic, C#, C++ и т.п.) есть возможность создавать так называемые перегруженные функции, или функции с разным количеством и / или типом параметров. В AutoLISP / VisualLISP подобной возможности не предусмотрено. То есть если пишется функция создания, например, отрезка, то ей должны передаваться сразу все параметры: начальная и конечная точки, пространство-владелец создаваемого объекта (точнее, указатель на него), тип линии, цвет, и еще безумное количество устанавливаемых свойств. Запомнить их последовательность нереально, особенно учитывая тот факт, что в VLIDE напрочь отсутствует технология IntelliSence. Но не все так плохо. Обойти это ограничение можно и нужно. Об этом и поговорим.
Далее
Многосточный текст в ADT2005
В файле, изначально созданном в ADT2005 Rus + SP1, есть достаточно большой многострочный текст (3200 символов или около того; то есть до ограничения в 32565 символов, неявно прописанном в объекте MTEXT, еще очень и очень далеко). Попытки редатировать этот многострочник с использованием внутреннего редактора через 3-4 попытки приводят к сообщению типа "Unhandled Access Violation <...> at 3689beh".
Поиск в гугле по адресу ошибки ни к чему не привел (похоже, это достаточно уникальная ситуация); поиск по словам "mtext editing" - только к достаточно старым рекомендациям поменять whipthread и whiparc. Скажу честно: попробовал все. Результат - нулевой.
Памятуя о собственных играх с lisp, зашел в vlide и выполнил нечто типа
1 | (setq txt (vla-get-textstring (vlax-ename->vla-object (car (entsel))))) |
А потом (тут же!) скопировал в буфер возвращенное значение и попытался
1 | (setq txt1 "<И здесь строка>") |
Строка была нечто типа
1 | ; error: string too long on input |
Причина появления неизвестна, но как бороться уже более понятно: просто "разобьем" многострочник на 2-3 куска поменьше. Да, неудобно. Да, некрасиво. Но зато работает достаточно устойчиво.
