Продолжаю войну с меню…
Как было сказано в статьях, упомянутых в Последовательность загрузки приложений, можно организовать загрузку своих приложений, используя mnl-файлы. Чем я до поры до времени успешно и пользовался.
Но, к сожалению, не все так легко и просто.
Далее
Невозможно проверить dcl
Я предпочитаю создавать диалоги "на лету" (пример можно посмотреть здесь). Но иногда бывает, что dcl достаточно сложен, и хочется посмотреть, "что будет в результате".
Сохранили dcl-файл, открываем его в VLIDE, далее Tools -> Interface tools -> Preview DCL. И AutoCAD выдает ошибку "Can't open file ***\$vcl$.dcl". Ситуация может встречаться в ЛВС уровня предприятия на компьютерах включенных в домен. На домашних компьютерах я с таким не сталкивался, но от этого не легче. Вопрос - что делать?
Далее
Работа с xml
Чем дальше, тем больше AutoCAD и продукты на его основе "завязываются" на xml. Понятно почему: удобный вариант хранения сколь угодно сложной структуры, парсер гарантированно встроен в систему ну и теде.
Достаточно давно я разработал набор функций, которые позволяют нормально работать с xml-документом. Как выяснилось в процессе работы, в основном стоит задача чтения данных (благо заполняю я xml-файлы либо в Notepad++, либо в Microsoft XML Notepad, либо в MS Visual Studio). Но - функции есть, и предоставлю я их целиком.
Предупреждаю сразу: пост получился очень длинный, набор функций, как всегда, в самом конце
P.S. Функции не переименовывал. Кому охота - код открыт, используйте наздоровье
P.P.S. Аналог всего этого дела был в свое время опубликован у меня на блогспоте, так что не удивляйтесь возможным повторам :).
Далее
.NET, arx и atoms-family
Есть такая функция в лиспе - atoms-family. По идее должна показывать зарезервированные символы AutoLISP / VisualLISP. Но, кроме заявленного функционала, она может показать пользовательские команды и функции, загруженные в текущий документ.
Далее
Область видимости, как ее игнорируют. И как лечить. Локальные и глобальные шутки.
Сегодня был очень интересный разговор, суть которого свелась к вопросу: "Если есть несколько кодов lsp от разных авторов, то как быть с повторением имен функций?" Действительно, в LISP нет (как бы) понятия public и private, но есть локальные функции и параметры. Честно говоря, я уже не помню, разговор был или нет про это дело. Но если был, то ничего страшного - слегка повторимся.
Далее
Как обновить вхождения блока
Понадобилось мне тут обработать достаточно насыщенный файл dwg, в котором приличное количество блоков с несколькими уровнями вложенности. В процессе обработки приходилось еще и менять стили в текстах, которые были внутри блоков. Да и про атрибуты тоже забывать нельзя. Регенерацию в силу некоторых причин применить было невозможно (и прежде всего оттого, что занимало это дело немеряно времени. Да и тот факт, что в некоторых случаях у меня это дело не срабатывало, тоже сыграл свою роль...).
Казалось бы, решение очевидно: брать описание блока, менять его, потом брать вхождение блока и для него vla-update или entupd.
Далее
О кодах, загрузке и компиляции. Часть 2.
Продолжим начатое здесь.
Загрузка lsp сама по себе, конечно, интересна, но... Но быстродействие скомпилированного fas'a может быть в несколько раз выше. Разберем компиляцию сборника lsp в единый fas-файл.
Далее
О параметрах вызова и “перегрузке” 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 куска поменьше. Да, неудобно. Да, некрасиво. Но зато работает достаточно устойчиво.
Особенности vla-функций и их применения, часть 2
В предыдущей части уже были рассмотрены некоторые особенности работы vla-функций применительно к графической составляющей dwg-файла. Но были рассмотрены далеко не все вопросы. В частности, не было освещено "создание примитива через ActiveX без явного указания необязательных настроек". И никак не был затронут вопрос о модификации созданного примитива (точнее, удобства и очевидности изменения).
Далее