Перейти к содержанию

Адаптация Lisp под Nanocad


Рекомендуемые сообщения

15 часов назад, lidia.antipina.ru сказал:

Насчет StripMtext v5-0c1_NC.lsp вызывает сомнение обработка команд VBScript.RegExp


Меня больше огорчило то, что в NC21 не сработала даже та часть скрипта, что сработала в NC20.

 

Кстати, с полями при применении txt_edit_NC та же самая фигня.
Повторяем предыдущий эксперимент и получаем из

Спойлер

image.png.1144973cdb7707edd54f9cc5578b402c.png



в AutoCAD все нормально:

Спойлер

image.png.bc83d046602df965c9466d9fed992d79.png

 

а в nanoCAD 20/21 после применения команды поля исчезают

Спойлер

image.png.452f4df5bf142c7f9703811125740943.png

 

Спойлер

image.png.704e8e2a560b199db530b5002ff27912.png

 

С другой стороны, хорошо, когда есть хоть что-то стабильное.

P.S.
А нельзя сделать так, чтобы информационное пространство статей форума занимало несколько побольше жизненного пространства браузера ?

Спойлер

image.thumb.png.8045509923c68562e28c6fec785a7806.png


 

Изменено пользователем A.Kudrjashov
Дополнения
Ссылка на сообщение
Поделиться на другие сайты
  • Ответов 119
  • Дата создания
  • Последний ответ

Лучшие авторы в теме

Лучшие авторы в теме

Популярные посты

Есть еще txt-edit_Nc.lsp - удаляет форматирование для всего файла или выборочно.   Для сброса цвета - см. bgtools 3.11a_Nc_21.lsp - работающие команды отмечены + в BGINFO.   Насчет Stri

Попытался переписать функцию BounderyMText с применением входных параметров. В скрипте внес достаточно подробные комментарии, а также привел варианты вызова функции с различными параметрами. Запр

В продолжение темы. Конечно, победить метод 'Replace мне не удалось. Но, возможно, на наше счастье метод 'Execute работает штатно, что позволило внести некоторые изменения в код (извиняюсь з

Изображения в теме

15 часов назад, lidia.antipina.ru сказал:

Для сброса цвета - см. bgtools 3.11a_Nc_21.lsp - работающие команды отмечены + в BGINFO.

 

BGCOLOR в NC20.x работает нормально, [хотя и пишет, что

Спойлер

image.png.bd891b482c9e591c9e428d73af488452.png

 

а в NC21.x после применения не позволяет выполнить Undo ни из командной строки, ни из верхней панели.

Спойлер

image.png.1cfdeb83832901441f5f753caded7003.png

 

Создается ощущение, что у LISP под nanoCAD перспективы не самые радужные.

 

Ссылка на сообщение
Поделиться на другие сайты

Тестировала под Win 10 Pro, у Вас какая?

добавлено через 6 минут
1 час назад, A.Kudrjashov сказал:

Создается ощущение, что у LISP под nanoCAD перспективы не самые радужные.

Перспективы нормальные, но сложно бежать вдогонку за продуктом с начальным отставанием в 20 лет. Вы же знаете, что программ без ошибок не существует в природе

Ссылка на сообщение
Поделиться на другие сайты
12 минут назад, lidia.antipina.ru сказал:

Тестировала под Win 10 Pro, у Вас какая?

На данном рабочем месте Windows 7. Но, если еще и это будет влиять !

Конечно, программ без ошибок не бывает. Печально, когда в новой версии ошибок становится больше.

Ссылка на сообщение
Поделиться на другие сайты

Тоже попытался погрузиться в проблемный код.

В результате докопался до очень неприятной проблемы.

Вся логика работы программы основана на замене пустой символьной строкой определенной последовательности символов форматирования.

При этом интерфейсная часть формирования списка параметров и захват объектов вроде работают корректно.

Даже окно свойств сохраняет свои значения при запуске обеих САПР - NС и АС

 

Выявлено различие в реализации функции (defun RE:Replace ... в NС и АС., а именно в части метода 'Replace

Спойлер

image.png.6e3e9aec1f25d5c75925c7dff2cc83d2.png

 

Судя по всему, в нанокаде неверно применяются маски 'Pattern.

Например:

 маска pat = "\\\\[Ff].*?;" применяется для поиска имени файла шрифта.

 маска pat = "\\\\W[0-9]?[.]?[0-9]+;" применяется для поиска фрагмента изменения ширины символов.

 

Выяснилось, что в NC метод 'Replace при применении этих масок не заменяет найденные фрагменты, а просто "обнуляет" всю строку. в АС происходит "обнуление" только фрагмента, отвечающего маске

 

 

Вполне возможно, что разработчикам удастся оперативно найти исток проблемы. Возможно, имеет место просто тупая замена внутри функции-метода 'Replace одной переменной (фрагмент) другой переменной (вся строка). Такую ошибку достаточно легко исправить.

 

В нашем же случае это является очень труднопреодолимым препятствием, т.к. реализация метода нам-пользователям недоступна.  Хотя, можно попробовать самостоятельно написать прямо внутри функции RE:Replace собственный парсинг строки. Но это довольно хлопотное и кропотливое дело.

 

Я бы порекомендовал использовать лиспы из перечисленных выше, пусть не столь всеобъемлюющих, но достаточно функциональных.

 

Ссылка на сообщение
Поделиться на другие сайты

Создан дефект. Год назад было поправлено для передачи строки с символом \0, но вероятно не совсем корректно

 

Ссылка на сообщение
Поделиться на другие сайты
В 21.10.2021 в 12:56, lidia.antipina.ru сказал:

Вы же знаете, что программ без ошибок не существует в природе

Спойлер

Конечно знаем, но знание и вера две разных категории. А в nanoCAD мы верим)

 

Ссылка на сообщение
Поделиться на другие сайты

В продолжение темы.

Конечно, победить метод 'Replace мне не удалось.

Но, возможно, на наше счастье метод 'Execute работает штатно, что позволило внести некоторые изменения в код (извиняюсь за корявость этих изменений) и добиться работоспособности программы.

 

Протестировать на всех видах объектов не удосужился.

Внесены были только точечные изменения для реализации функции замены подстроки.

Можете попробовать доработанный вариант, файл в атаче.

StripMtext v5-0c-nanо.lsp

Ссылка на сообщение
Поделиться на другие сайты
14 часов назад, EdwardSt сказал:

Можете попробовать доработанный вариант, файл в атаче.


Под NC20.1 сразу выпадает ошибка Undo.

Спойлер

image.png.890abfedff8370930073fc3b293f43b3.png

 

Под NC21.0 поле точно также исчезает

Спойлер

image.png.91b408961621b26abd3f7444d65d7ade.png

 

Спойлер

image.png.e63a66269c6b9825b8dc3fab34f09bbf.png

 

Спойлер

image.png.6a7855a978ae7a37b754b67ec2d4e04c.png

 

P.S.
Я думаю, что, если есть большая потребность, то лучше не спеша написать заново. Как минимум, код будет под полным контролем.
В nanoCAD что-то работает принципиально не так, как в AutoCAD. И, вообще, о кросс-платформенных (NC/AC) LISP кодах, похоже, лучше не мечтать.

 

Ссылка на сообщение
Поделиться на другие сайты
3 часа назад, A.Kudrjashov сказал:


Под NC20.1 сразу выпадает ошибка Undo.

  (1) (Скрыть контент)

image.png.890abfedff8370930073fc3b293f43b3.png

 

Под NC21.0 поле точно также исчезает

  (2) (Показать контент)

image.png.91b408961621b26abd3f7444d65d7ade.png

 

  (3) (Показать контент)

image.png.e63a66269c6b9825b8dc3fab34f09bbf.png

 

  (4) (Показать контент)

image.png.6a7855a978ae7a37b754b67ec2d4e04c.png

 

P.S.
Я думаю, что, если есть большая потребность, то лучше не спеша написать заново. Как минимум, код будет под полным контролем.
В nanoCAD что-то работает принципиально не так, как в AutoCAD. И, вообще, о кросс-платформенных (NC/AC) LISP кодах, похоже, лучше не мечтать.

 

Я везде втыкаю проверку версии nano для startundomark, endundomark. Аналогично для  нереализованных/не нужных/устаревших сисваров

if_nano.lsp

добавлено через 7 минут
3 часа назад, A.Kudrjashov сказал:

о кросс-платформенных (NC/AC) LISP кодах, похоже, лучше не мечтать.

Почему, все достижимо. Но надо иметь ввиду, что старые лиспы часто тащут историю от царя гороха, причем можно написать гораздо проще. А еще перед этим пробежаться по списку реализованных команд nano, может этих лисп-функций уже не требуется

Изменено пользователем lidia.antipina.ru
Ссылка на сообщение
Поделиться на другие сайты
36 минут назад, lidia.antipina.ru сказал:

Почему, все достижимо. Но надо иметь ввиду, что старые лиспы часто тащут историю от царя гороха, причем можно написать гораздо проще.


Если бы проблема была только в истории или объеме ...
Проблема в том, что функционал не работает, как предполагается. То есть, кроме принципиального решения задачи и отладки кода, необходимо еще параллельно искать нестыковки в реализациях ACAD/nanoCAD или NC20.x/NC21.x.

У подавляющего числа пользователей, а LISP автоматизация ориентирована прежде всего на обычных  [продвинутых] пользователей, просто нет столько времени копаться в чужом коде.

Ссылка на сообщение
Поделиться на другие сайты
36 минут назад, lidia.antipina.ru сказал:

Если переписывать лиспы, то предпочтительно, используя COM (vl-, vla-, vlax)

Это более эффективно, но менее универсально.

Я все-таки не оставляю попыток делать лиспы максимально универсальными, независимыми (или минимально зависимыми) от платформы. Поэтому vl* - функциям перехожу только когда совсем лениво и затратно реализовывать на классических функциях автолиспа.

Возможно, это слишком оптимистичный подход - доверять разработчикам в том, что более старые функции уж_точно_вылизаны_до_предела, но я исхожу именно из этого посыла.

Ссылка на сообщение
Поделиться на другие сайты
4 часа назад, A.Kudrjashov сказал:

Под NC21.0 поле точно также исчезает

  (2) (Скрыть контент)

 

Ваш тестовый пример очень хорош для отладки, за что отдельное спасибо.

На нем в частности выявил, что и исходная программа в АС14 неверно справляется с некоторыми конструкциями. Например, поле в ячейке таблицы обработать программа не может и аварийно вываливается.

 

Еще раз оговорюсь, весь функционал не тестировал. Описание полей внутреннего форматирования в многострочном тексте очень уж развесистое. Постарался устранить только очевидную ошибку некорректной замены фрагмента текста другой текстовой строкой (что, вроде бы удалось). А вот то, что при изменении текста теряется связь с полем, - это уже более глубинный вопрос к потрохам нанокада, выходящий за рамки просто обработки текстовой строки, и мною не рассматривался. 

 

  

Ссылка на сообщение
Поделиться на другие сайты

Синтаксический разбор вызовов LISP модулей (PowerShell)
https://forum.nanocad.ru/index.php?/blogs/entry/82-sintaksicheskiy-razbor-vyzovov-lisp-moduley-powershell/

... в первом приближении.

Ссылка на сообщение
Поделиться на другие сайты

Коллеги,а у кого то есть Лисп который делает ширину однострочного мтекса по ширине самого текста? Например сам текст шириной 10 единиц , а самое поле мтекста 35 единиц. И надо чтоб бы Лисп сделал ширину текста из 35 к 10. Лиспы которые рассматривались выше, где позиции(чекбоксы) "ширина" 'высота" думал решают эти проблемы, оказывается нет (это все надо для того, чтоб сделать корректный  фон у текста), спасибо

 

 

Изменено пользователем aerohost
Ссылка на сообщение
Поделиться на другие сайты

Файл в атаче

 

Там первая функция - примитивный выбор объекта.

Без проверки, что выбран мтекст, и без остальных изысков. 

Если есть необходимость, можно усложнить выбор.

 

И вторая функция - собственно изменитель МТекста (ширина, высота и масштаб рамки заливки)

BoundMText.lsp

Ссылка на сообщение
Поделиться на другие сайты
59 минут назад, EdwardSt сказал:

Файл в атаче

 

Там первая функция - примитивный выбор объекта.

Без проверки, что выбран мтекст, и без остальных изысков. 

Если есть необходимость, можно усложнить выбор.

 

И вторая функция - собственно изменитель МТекста (ширина, высота и масштаб рамки заливки)

BoundMText.lsp 508 \u0411 · 3 загрузки

все класс, работает, но с выбором беда, только поштучно,  если можно было бы массово выбирать, было б просто замечательно.  Попробую сам, что нибудь накрутить, спасибо !

Изменено пользователем aerohost
Ссылка на сообщение
Поделиться на другие сайты
5 минут назад, aerohost сказал:

но с выбором беда, только поштучно,

Тут только вопрос в пожеланиях)))

Изначально речь шла об изменении текста. А способ выбора, проверка на дурака и т.п. - это отдельное ТЗ.

Уточните требования и попробуем помочь

Ссылка на сообщение
Поделиться на другие сайты
13 минут назад, EdwardSt сказал:

Тут только вопрос в пожеланиях)))

Изначально речь шла об изменении текста. А способ выбора, проверка на дурака и т.п. - это отдельное ТЗ.

Уточните требования и попробуем помочь

Все тоже самое, только не каждый раз выбирать поштучно мтекст, запустил ЛИСП выбрал скопом Мтекста и все.Спасибо!

 

Ну еще было б неплохо, если лисп не будет брать в оборот пробелы, считал бы их как символ.  Но это не столь важное, главное скоп реализовать бы :))

 

Ну если красиво делать, можно задать условие, Да\нет скрытый фон  Мтекста :))

 

Спойлер

1172852859_UntitledProject.thumb.gif.c359d05fa30a73baf2ecdc6a102db0f5.gif

 

Изменено пользователем aerohost
Ссылка на сообщение
Поделиться на другие сайты

Чем дальше в лес, тем толще партизаны)))

Задача обрастает пожеланиями с неимоверной скоростью.

 

Тут сразу несколько контр-вопросов:

1. Выбор.

  • Учитывать предварительный выбор и использовать его или только запрос новых
  • Отфильтровывать МТексты в момент выбора (в том числе и в предварительном выборе) с соответствующим сообщением или сначала выбрать, а потом применить изменения только для мтекстов

2. С пробелами не совсем понял. Приведенная программа определяет реальные размеры прямоугольника мтекста и заменяет ими исходные, которые доступны для редактирования через окно свойств или через ручки

Спойлер

image.png.30f5325c1d805a244d07905bd0c51d35.png

Если имеется ввиду перенос в строке по достижении пробела, то это значительно более сложная задача.

Т.е. примерно следующий алгоритм: сначала увеличение ширины текста на невообразимую величину, а уже после этого применить исходный алгоритм, который уменьшит пользовательскую ширину до реально получившейся. Не уверен в разумности такого алгоритма. Запросто можно  наворотить нежелательные изменения.

 

3. включение/отключение заднего фона регулируется опять же через окно свойств. Приведенный лисп только меняет масштаб рамки фона (по умолчанию он 1,5), если такой параметр присутствует. Если необходимо включение/отключение непосредственно в программе, то это усложняет ее дополнительным соответствующим запросом. Там дальше появятся вопросы о цвете фона, использовать ли фиксированный цвет и т.п.

 

PS. Как всегда, интерфейсная часть (все эти вопросы-галочки, что, если и т.п.) - самая тяжеловесная часть программы. По моему опыту это 90% кода и результат не всегда всех устраивающий. Т.к. обязательно кто-то захочет еще расположить в углу котенка. Поэтому, как освобожусь, постараюсь сделать компромиссный вариант с запросом или использованием предварительного выбора. Остальные пожелания - "неучет" пробелов в тексте, включение/отключение фона и запрос цвета - не обещаю.

Ссылка на сообщение
Поделиться на другие сайты
1 час назад, EdwardSt сказал:

Чем дальше в лес, тем толще партизаны)))

Задача обрастает пожеланиями с неимоверной скоростью.

 

Тут сразу несколько контр-вопросов:

1. Выбор.

  • Учитывать предварительный выбор и использовать его или только запрос новых
  • Отфильтровывать МТексты в момент выбора (в том числе и в предварительном выборе) с соответствующим сообщением или сначала выбрать, а потом применить изменения только для мтекстов

2. С пробелами не совсем понял. Приведенная программа определяет реальные размеры прямоугольника мтекста и заменяет ими исходные, которые доступны для редактирования через окно свойств или через ручки

  вот эти (Показать контент)

image.png.30f5325c1d805a244d07905bd0c51d35.png

Если имеется ввиду перенос в строке по достижении пробела, то это значительно более сложная задача.

Т.е. примерно следующий алгоритм: сначала увеличение ширины текста на невообразимую величину, а уже после этого применить исходный алгоритм, который уменьшит пользовательскую ширину до реально получившейся. Не уверен в разумности такого алгоритма. Запросто можно  наворотить нежелательные изменения.

 

3. включение/отключение заднего фона регулируется опять же через окно свойств. Приведенный лисп только меняет масштаб рамки фона (по умолчанию он 1,5), если такой параметр присутствует. Если необходимо включение/отключение непосредственно в программе, то это усложняет ее дополнительным соответствующим запросом. Там дальше появятся вопросы о цвете фона, использовать ли фиксированный цвет и т.п.

 

PS. Как всегда, интерфейсная часть (все эти вопросы-галочки, что, если и т.п.) - самая тяжеловесная часть программы. По моему опыту это 90% кода и результат не всегда всех устраивающий. Т.к. обязательно кто-то захочет еще расположить в углу котенка. Поэтому, как освобожусь, постараюсь сделать компромиссный вариант с запросом или использованием предварительного выбора. Остальные пожелания - "неучет" пробелов в тексте, включение/отключение фона и запрос цвета - не обещаю.

Да я уже накрутил фильтр и скоп, чуть попозже попробую накрутить фон, если получться. Если у вас получится быстрее фон накрутить, то круто  ! я непрофи в lisp  и кодинге

 

 

upd:

Разное поведение  lispa на разный Mtext, где перенес текст на новую строку (где был пробел) , этот Мтекст был создан в старых версиях Ncad, А где не перенес текст на новую строку, этот Mtext был создан в (ncad 11,20,21)  Ну и ладно, так тоже хорошо 

Спойлер

1224978104_UntitledProject.thumb.gif.a8653cd1e97fe41f003392850dbe0407.gif

 

BoundMText.lsp

Изменено пользователем aerohost
Ссылка на сообщение
Поделиться на другие сайты
41 минуту назад, aerohost сказал:

upd:

Разное поведение  lispa на разный Mtext,

Пример не понял. Можно сам файл *.dwg с одной из надписей?

 

Для отключения фона достаточно добавить

     (setq da (subst (cons 90 0) (assoc 90 da) da))

 

Для включения фона: (cons 90 1) или  (cons 90 2), и дополнительная установка цвета (использование DXF-групп 63, 420 - 439)

 

 

Изменено пользователем EdwardSt
Ссылка на сообщение
Поделиться на другие сайты
22 часа назад, EdwardSt сказал:

Пример не понял. Можно сам файл *.dwg с одной из надписей?

 

Для отключения фона достаточно добавить

     (setq da (subst (cons 90 0) (assoc 90 da) da))

 

Для включения фона: (cons 90 1) или  (cons 90 2), и дополнительная установка цвета (использование DXF-групп 63, 420 - 439)

 

 

Вроде как сделал, вроде как работает и в тоже время не работает скрытие фона.

 

Если с помощью лиспа делать скрытие фона вновь созданного МТЕКСТА, по лисп почему то не работает. 

Но если у МТЕКСТА вручную установить фон, потом с помощью Групповые коды DXF 90 поставить на 2( скрыть фон), потом поставить DXF 90 поставить на 3 ( показать фон) то все работает( Это отображено в конц gif). Кто знает в чем причина ?  Такое ощущение, что у вновь созданного МТЕКСТА как будто не существует  DXF 90, при ручной операции он появляется, и получается с помощью лиспа получается перезаписывается  DXF 90 на 0 1 2 3.

 

Я так понимаю ошибка в коде лиспа, который перезаписывает DXF 90 (Если он создан\существует), а реализовать  надо, что бы не перезаписывал, а создавал новый при его отсутствии

Спойлер

146847185_UntitledProject.thumb.gif.09484a9a3795056743d8c47b48331dd6.gif

mtext.dwgBoundMText.lsp

Изменено пользователем aerohost
Ссылка на сообщение
Поделиться на другие сайты
4 часа назад, aerohost сказал:

Вроде что то сделал, но не работает... я про маску текста, посмотрите, может решится проблема в два клика) mtext.dwgBoundMText.lsp 

Сейчас немного занят...

Но практически сразу обозначилась проблема по поводу переноса в МТексте.

Обращаю внимание, что она не связана с лисповски скриптом!

Наблюдается проблема на уровне интерпретации DWG-формата.

Для демонстрации подготовил пример с проблемной надписью.

Тестовый Мтекст скопировал на новое место и применил к нему скрипт, изменяющий пользовательские размеры мтекста до его реальных текущих.

 

Спойлер

image.thumb.png.8f0d68321ddc9467088ee7f2e87e9f9d.png

Наблюдаем корректное изменение размеров (прямоугольник полностью охватывает мтекст, ручки строго в углах прямоугольника, фон распространяется на целевой прямоугольник текста) 

 

 

Спойлер

 

 

image.png.9b45a8c96761286c21fba0ca60effd73.png

Наблюдаем корректное изменение размеров, о чем свидетельствуют ручки и значения в окне свойств.

Но NC не "вписался" в определившиеся размеры (причем, корректно определившиеся!), осуществил перенос текста по символу пробела и закрасил фон уже по новому получившемуся прямоугольнику.

Если еще раз попробовать изменить границы, то наблюдаем

 

Спойлер

image.png.c50a9562c2c1272bfc3feaac6c5b121a.png

 

Прямоугольник, фон и ручки сошлись ожидаемым образом.

Но не так, как задумывал пользователь!

 

 

Интерпретация результата:

Лисповская программа в среде NC корректно определила реальные занимаемые размеры мтекста, корректно присвоила их пользовательским размерам мтекста, но дальше NC не вписывает мтекст в правильно определенные размеры и вставляет перенос. Считаю это однозначным багом, на который обратят внимание разработчики, т.к. сохраненный в NC файл правильно отображается в АС, в отличие от NC.

 

Для купирования проблемы в скрипте можно применить костыль в виде

(setq s (* (cdr (assoc 42 da)) 1.001) ... 

Т.е., увеличить ширину на 0.1%. Глазу незаметно, а результат вроде близок к искомому.

Высоту менять нет необходимости.

mtext-дефект.dwg

Изменено пользователем EdwardSt
Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Восстановить форматирование

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

Загрузка...
  • Расскажите друзьям

    Нравится Официальный форум компании Нанософт? Расскажите друзьям!

×
×
  • Создать...