Jump to content

EdwardSt

Пользователи
  • Posts

    862
  • Joined

  • Last visited

  • Days Won

    34

Everything posted by EdwardSt

  1. В нашей практике их обычно в модели и делают. Ну а плоскость, соответственно, может и не совпадать с XOY. Ну и опять же, как там у конкурента? Мультивыноска по-честному рисуется из точки, которую указал (со своей Z в ПСК), а дальше все элементы создаются в плоскости, параллельной XOY этой ПСК. В отличие от наны, где стрелка рисуется в плоскости МСК независимо от установленной ПСК, а текст параллелится с XOY ПСК, т.е. текст и стрелки рисуются в полном рассинхроне. ЗЫ. Соскочили мы с темы ветки. Пардоньте
  2. Баловство это все. Поправили flatten - хорошо. Но цена этого - возможность создания всех вычурных выносок исключительно в XOY(Z=0) МСК. Т.е., ПСК просто игнорируется. А стандартная мультивыноска - вообще еретически строится в ПСК - ни в МСК (как остальные выноски), ни по-честному в ПСК (чтоб и текст, и все полки-стрелки). Я понимаю, что подавляющее количество чертежей именно в МСК и делается, и тогда все это брюзжание неактуально. Но такая реализация - это заведомое сужение возможностей. С учетом перехода на 3Д это вообще может стать тормозящим фактором.
  3. Во как! Прошло мимо моего внимания. Спасибо за наводку. Настолько уже свыкся с мыслью, что использовать эти элементы низя, что и не проверял. Правда, их и сейчас использовать у нас не получится. Одновременно используем и Nano, и АС. Редактировать эти объекты в АС невозможно. Дано указание проектировщикам использовать только стандартные выноски.
  4. И незачем приумножать проблемы! Что касается Nano-таблиц, то одновременно с ними введен и механизм преобразования в dwg-таблицы, что как-бы извиняет вольности разработчиков. А вот выноски - это отдельная головная боль. И особенно их аннигиляция при команде FLATTEN - это нечто! В общем, лучше "ни одним больше". ИМХО
  5. Старый добрый ворд в помощь. Формулы набил в ворде (или вставил откуда-нибудь), а уже оттуда ктрл+Ц,В и получи Оле-объект. Выше писали про совместимость на уровне dwg-формата. В данный момент нет адекватных структур данных для хранения столь заковыристо отформтированного текста. Создание своего объекта, который будет проксЁй в АС, - это по сути запрос на создание фичи в рамках вертикального приложения. Реализовывать в рамках платформы нецелесообразно ввиду пресловутой совместимости. В рамках других вертикалок - обделять остальных пользователей. А вот модуль СПДС - универсальный расширитель платформы - вполне мог бы нечто такое в себя включить. Но насколько целесообразно заморачиваться созданием такой фичи в условиях, когда полноценно пользоваться результатом можно будет исключительно в СПДС (в остальных кадах это будет прокси) - вопрос очень спорный. Особенно при наличии механизма OLE-объектов, сносно работающего во всех системах. Возможно, более разумным выходом было бы "допиливания" механизма OLE-объектов, чтобы не появлялись белые или черные квадраты, чтобы он работал более устойчиво.
  6. Красивый пример. Понятно, что в каждом случае может быть разный набор наиболее удобных функций. И delSubRight - весьма интересная из них. Просто нужно помнить, что удаляются все символы (а не один!), присутствующие в наборе. Если в последнем элементе последний(е) символ(ы) будет(ут) в списке на удаление во втором аргументе, то может быть потеря информации. Весь вопрос только в том, насколько это критично и реалистично.
  7. Хотя Правая колонка - по-старому, левая - помоднее. Ну и еще один способ из старых - в атаче Обработка последнего символа в группировке. delSubRight_v2.1.dwg
  8. И эта ссылка, и приложенный файл не грузились. Но сейчас работает. Спасибо. Видать, был какой-то локальный глюк.
  9. За что свою порцию лайков (и от меня - в том числе) тогда же и получил
  10. Просто оставлю это тут https://autolisp.ru/2020/12/04/net-vs-lisp/ Ну да, и скорость тоже (иногда). Если сравнивать скорость, то корректнее сопоставлять с компилированным лиспом. Все-таки, автолисп реализован в АС, как интерпретатор. т.е. по определению нешустрый. Но на современных машинах чаще всего скорость выполнения не является основным критерием, проектировщик чешет репу и двигает мышкой на несколько порядков медленнее. Времена, когда наблюдаешь на экране мультфильм на несколько десятков секунд из полстроения примитивов, прошли еще в эпоху 486DX процессоров. Поэтому, каждому средству программирования всегда найдется ниша оптимального применения.
  11. Пока хватает возможностей Lisp, лучше продолжать пользоваться им. ИМХО Конечно, интерфейсные элементы откровенно слабы, но остальное - вполне на уровне. А зачастую - куда эффективнее.
  12. Замысловатая картинка получается. Подготовил примерчик (в аттаче). Протестированы последовательности чисел на предмет округления ("вниз" и пусто, где "верх", - для наглядности). Отмечу, что по правилам математического округления (наиболее распространенный случай) округление 0,5 должно быть вверх. Что занятно, лисповская функция (rtos тоже жжет! Протестировал простенький скрипт с округлением последовательности чисел. Первые два числа округляются вверх, остальные - вниз И в обратном порядке. Первое число округляется вниз, остальные - вверх И вишенка на торте Наблюдаем некоторое расхождение с лисповским результатом (опять же, система неуловима). Но так же видим, что в правой таблице ВСЕ значения округлились вверх, а в левой - в разнобой. Отмечу, что значение аргумента формировалось автоматически, как Ai=Ai-1 + 0.01 для таблицы слева и Ai=Ai-1 - 0.01 - для таблицы слева. Единственным объяснением такого обескураживающего результата может быть то, что операции с плавающей точкой тоже выполняются с некоей погрешностью машинной сетки и далее с непредсказуемыми результатами. Вот только пользователя такое объяснение вряд ли удовлетворит. Действительно, косяк присутствует. Причем, как в части необъяснимости примененного метода (когда есть явные функции округления вниз, вверх и как-бы до ближайшего), так и в одинаковости результата для аргумента, полученного разными методами, но одинакового в конечном виде. Особенности округления.dwg
  13. Мудреные тут у вас разговоры получаются). Но все-таки хотел бы еще раз вернуть немного на исходные позиции: 1. Файл А - лагает (Подтверждено всеми участниками обсуждения). 2. Включенный файл А в виде ссылки в новый файл - лагает (никем не оспорено). 3. Упакованный в один единственный блок весь файл А и сохраненный в файле Б путем внедрения ссылки из п.2 - не лагает. (Подтверждено всеми участниками обсуждения) 4. Отдельная досада - у меня этот блок так и не разбирается, в отличие от других собеседников 5. Пп. 1 - 3 выполняются на одной машине, т.е. общие настройки программы и видеоподсистемы одинаковые. 6. Описанные безобразия наблюдаются в 22 и не наблюдаются в 20.1 Т.е., проблема заключается в способе обработки элементов чертежа. Я не совсем понимаю, чем отличается пересчет при прохождении курсора над одним блоком и над группой объектов, включенных в блок. Допускаю, что есть некий хитрый алгоритм, существенно повышающий производительность этого дефиле курсора по полю чертежа. Это объясняет (может объяснить) причину, но остается вопрос - что с этим делать? ЗЫ. Если проблема решена в новой сборке, то и ладненько. Хотя проблемы, не решенные в прошлом, но каким-то образом обойденные в момент своей актуальности, имеют свойства "выстреливать" снова и снова.
  14. После отмены на форме все равно остается измененный профиль? Проверил самостоятельно. Да, профиль изменился даже при отмене. Косяк, однозначно.
  15. Кривовато выглядит. Но, я так понимаю, это же сообщение появится при закрытии формы ("Параметры"). Для некоторых пунктов, например лицензирование, будет то же самое. По-видимому, посыл следующий: тут просто предупредили, часть настроек поменяли, но полное применение только после перезагрузки программы, о чем будет повторное предупреждение. Отказаться от части внесенных изменений можно при отмене формы параметры. Но ввиду групповой операции - изменения сразу нескольких настроек - по хорошему в первом сообщении тоже должна быть кнопка отмены именно для этой группы. Это вопрос удобства, но не общей функциональности.
  16. Все пусто. Ну и в любом случае, загружены два чертежа. В одном тормозит, в другом - нет. Т.е., влиять может только содержимое чертежа, а не состояние приложения. Будем надеяться, что проблема станет неактуальной в новой сборке.
  17. Закрыт. Но сегодня аварийно прерывал около 10 раз. Возможно, нужно полностью перегрузиться и попробовать повторить. Иногда помогает...
  18. Очень надеюсь на это! Кстати, пересмотрел еще раз подготовленный пример и увидел неточность в своих выводах Файл Б содержит один элемент - блок, в который включены все 306к элементов файла А. И в таком виде (когда все элементы упакованы в один блок) он не лагает! Попытка разобрать этот блок не увенчалась успехом, терпения не хватило дождаться результата. Но в АС блок разобрался шустро. И после этого в NC файл тоже стал тормозить.
  19. Вообще-то могу дать еще более исходный файл. 61М. Я просто из него сделал выжимку, которая по-прежнему заметно тупит. Но изначальный исходник еще сильнее лагал. Если тест на релизной версии эффекта не возымеет, то свистите.
  20. По сути тут те же проблемы, что и в акаде. Ролики принтера ничего не знают о CADах. Они просто имеют размеры. У нас несколько лет назад был серьезный переполох, когда все чертежи, настроенные для печати на лазерник (в акаде) вдруг стали печататься без рамки при покупке нового МФУ. В вашем случае необходимо определить наиболее оптимальный способ из предложенных выше. Печать через промежуточный pdf - очень даже подходящий вариант. Тем более, что сейчас pdf - это один из обязательных результатов добавлено через 0 минут люто плюсую
  21. Стесняюсь сознаться, но ничего не понял ... Это?
  22. Все-таки, придерживаюсь мнения , что дело не в настройке графики. Т.к. А и Б у меня ведут себя по-разному. Независимо по одиночке или оба одновременно и в каком порядке запускаю: в 22 А тормозит, Б не тормозит
×
×
  • Create New...