О параметрах вызова и “перегрузке” 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-функций и их применения, часть 3
В предыдущих частях (здесь и здесь) велся разговор о графических примитивах. Здесь немного продолжим о них, но основной упор сделаем на неграфических элементах dwg-файла (стилях, слоях, описаниях блоков и т.п.).
Далее
Особенности vla-функций и их применения, часть 2
В предыдущей части уже были рассмотрены некоторые особенности работы vla-функций применительно к графической составляющей dwg-файла. Но были рассмотрены далеко не все вопросы. В частности, не было освещено "создание примитива через ActiveX без явного указания необязательных настроек". И никак не был затронут вопрос о модификации созданного примитива (точнее, удобства и очевидности изменения).
Далее
Особенности vla-функций и их применения
Если Вы (или Ваши клиенты) работаете только в мировой системе координат; если создаваемые Вами объекты никогда не будут иметь координату Z, отличную от 0; если Вы не хотите задумываться о трехмерном проектировании; если... Короче, если у Вас пляжные условия работы, то этот пост Вам неинтересен будет, скорее всего.
Если же Вы вынуждены работать (хотя бы иногда) не в мировой системе координат; если Ваши пользователи иногда (будем милосердными) устанавливают Elevation не 0 - то сейчас мы и будем говорить о проблемах работы в таких условиях и не всегда очевидными особенностями применения ActiveX.
Далее
Создание записей в таблицах стилей, слоев и т.п.
Как показала практика, приведенный пример не совсем жизнеспособен. Он прекрасно будет работать только в том случае, если в файле либо уже существует указанный текстовый стиль (и тогда выполняется его модификация), либо в файле с момента его открытия этого стиля еще не существовало.
Если же стиль был создан, а потом удален, то строка
1 |
tblStyle.Has(StyleName) |
вернет true, несмотря на то, что стиль имеет свойство IsErased = true. Что же делать?
Далее
Как же писать коды?
Прочитав статьи Стили программирования и Сравнение скорости выполнения кода, возникает вполне логичный вопрос: а как же писать? Через AutoLISP или VisualLISP?
Далее
Стили программирования
Как известно, есть 3 стиля программирования: "инженерный", "программисткий" и "объектный".
Их описания можно посмотреть здесь - ни отнять, ни прибавить. Но интересно не это, а качество кода.
Код пишется не просто так: обычно создаваемые объекты надо потом как-то обрабатывать. Поэтому критериями качества сейчас примем:
- длина кода
- устойчивость работы
- возможность получения созданного объекта
- легкость и прозрачность внесения изменений в объект.
Для конкретизации примера будем создавать объект отрезка и однострочного текста
Далее
Сравнение скорости выполнения кода
Не всегда, но бывает необходимо проверить - какой вариант функции работает быстрее. Здесь мы и рассмотрим уже готовый вариант.
Далее
Как сделать отмену результата выполнения?
Разрабатываемые коды, как правило, что-то делают с файлом dwg: рисуют объекты, вносят изменения в таблицы файла и т.п. При этом могут меняться системные переменные, отрисовываться временные примитивы и т.п.
Все будет замечательно, если пользователь сделает все сразу и верно. А если нет? А если понадобится отменять выполненную команду?
Далее