Динамическое изменение примитивов
Скажу честно: лично меня зрелище изменения примитивов чертежа "на лету" всегда завораживало. До очень многих вещей мне не дорасти (например, как показан здесь), но кое-что можно попытаться разобрать.
Далее
Преобразование единиц измерения блоков в файле
Известно, что при создании блока (ручного создания) можно указывать единицы, в которых этот блок будет вставляться: миллиметры, метры, дюймы и т.д. Это удобно, если гарантируется, что вся работа всегда выполняется на основе единственного шаблона с раз и навсегда настроенными единицами. Но бывает такое не всегда (да и за смежниками, бывает, приходится "доделывать").
Оптимальным решением, как ни странно, будут "безразмерные" блоки. То есть те, у которых единицы - "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. Но не все так плохо. Обойти это ограничение можно и нужно. Об этом и поговорим.
Далее
