Хранение пользовательских типов данных. Часть 3.2. ini-файлы.
Продолжаем разговор, начатый здесь и продолженный в части 3.1.
Далее
Как создать аннотативный стиль / описание блока?
По результатам обсуждения статьи "О создании стилей".
Начиная с 2008 версии в dwg появилось понятие аннотативности. О пользе этой вещицы здесь говорить не будем, попробуем разобраться с тем, как создавать аннотативность для стиля или описания блока, и как ее удалять при необходимости.
Далее
Хранение пользовательских типов данных. Часть 1. Данные внутри документа
Как я обещал, первая часть. Касается данных, требуемых в контексте только текущего документа. Текста будет немного (наверное).
Далее
О буфере обмена замолвим словечко…
О том, что такое буфер обмена, распространяться не буду - и так все знают. Где-то и когда-то я рассказывал про свое видение тонкостей работы с этим понятием в AutoCAD. Искать лениво, поэтому попробую высказаться тут.
Далее
Работа с неактивным документом
Подавляющее большинство лисп-функций, показываемых на форумах и сайтах, работают с текущим документом. Как правило, этого достаточно. Но что делать, если надо обрабатывать несколько документов? Здесь я хотел бы рассмотреть некоторые вопросы, связанные именно с обработкой неактивного документа.
Далее
Диалоговые окна dcl – зло? Или все же нет?
Редко какая программа обходится без взаимодействия с пользователем. Поскольку здесь разговор ведется именно о разработке для AutoCAD, уточняю: "редко какое пользовательское дополнение для AutoCAD обходится без взаимодействия с пользователем".
Можно запросить выбрать из контекстного меню опцию, а можно написать диалог. Вопрос: что выгоднее?
Ответа (по крайней мере однозначного ответа) лично я не знаю. Хотя для себя я выбрал правило: если запросов больше чем 3, надо задумываться о написании и вызове диалогового окна.
Далее
О кодах, загрузке и компиляции. Часть 2.
Продолжим начатое здесь.
Загрузка lsp сама по себе, конечно, интересна, но... Но быстродействие скомпилированного fas'a может быть в несколько раз выше. Разберем компиляцию сборника lsp в единый fas-файл.
Далее
О кодах, загрузке и компиляции.
Почти худлит получится, я думаю. Но тем не менее, поделиться хочется.
Разговор будет о том, как хранить созданные коды, как их загружать и компилировать. Естественно, что все написанное - сугубо личное мнение, и работать во всех условиях не будет. Но, может быть, кому-то и пригодится. Поехали?
Далее
Создание табличного стиля
В предыдущих частях вроде бы разобрались с созданием и модификацией текстового и размерного стилей. Так сказать, прочувствовали, что создание и изменение текстового стиля проработано просто превосходно (оба варианта - и entmake, и vla - отрабатывают просто отлично); что размерный стиль можно создавать только через entmake (если, конечно, вести разговор именно о LISP'e). Сегодня разберемся с табличными стилями.
Далее
Многосточный текст в 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 куска поменьше. Да, неудобно. Да, некрасиво. Но зато работает достаточно устойчиво.