EdwardSt

Конечно же бывает. Неудобство тут есть однозначно. Следовательно говорить об отсутствии совместимости не приходится. Но просто в командном режиме это не напрягает. Проблемы только в скриптах (например, обсуждалось в Если речь исключительно о командном режиме, то пока приходится мириться с отсутствием фичи. Реализацию же поддержки переменной EXPERT в нанокаде поддерживаю.

Это одно из перечня препятствий при переносе лиспов с АС в NC (на данный момент всех версий). Пока остается только искать костыли. Каждый раз проблема может решаться индивидуальным способом. Самый частый - стараться по максимуму уходить от функции (command .... Достойные (и, главное, универсальные!) аналоги присутствуют. Для более конкретных рекомендаций требуется взглянуть на код.

нанодев должен включать его в комплект поставки, вместе с костылями его - это бубен? )))

Действительно, одинаковые атрибуты не отображаются. Но при этом поиск блоков, содержащих такой одноименный атрибут, При этом на таком же выделении Явная недоработка от нанософта, хотя и ошибкой это можно не считать. добавлено через 7 минут А чего "огород городить"? Вопрос в том, как: На самом деле вопрос поставлен верно. @Bucho спросил про отображение одноименных атрибутов, а @Михаил_ЛМГТ про поиск блоков с одноименными видимостями. Очевидно, что это две разных задачи. И только вторая из них имеет адекватное решение.

Не изменяется в NC и АС14. Стараюсь всегда избегать аннотативных объектов, т.к. не умею ими пользоваться. Но всетаки хотелось бы задать вопрос: а как должно быть? Если у размера отключить аннотативность, то дальше меняется и высота текста с изменением масштаба символов. В чертеже установлена системная переменная в "показать все маассштабы" Если в АС добавить для размеров другие масштабы аннотаций, то их отображение (и масштаб) может регулироваться отключением этой системной переменной и переключением между масштабами. К сожалению в NC добавить масштабы аннотаций и установить текущий масштаб для элементов мы не можем. Поэтому остается только сбрасывать аннотативность и дальше уже шуровать в новых реалиях.

так не получится. Не работает почему то. Извиняюсь, не проверил работоспособность конструкции в NC. Отдельно попросил бы разработчиков обратить внимание на эту коллизию!!!! В АС это работает. Вот за это и не люблю функцию (command ... Нет никакой гарантии в полной совместимости. В общем, тем более имеет смысл уходить от использования этой функции по максимуму. В дополнение к изложенному методу от @Kreator рекомендовал бы к использованию функцию (entmake, Ее преимущество в том, что она вообще относится к базовым функциям автолиспа, не требует подключения к COM. Она напрямую работает со структурой объектов DWG и почти один в один соотносится с записями объектов при сохранении файла в DXF-формате. В вашем случае можно сразу создавать текст Итого два оператора: формирование списка и создание элемента. Первые три строки в операторе формирования списка - это обязательная часть, если хотим создать программно мтекст. Остальное на ваше усмотрение. При желании и с опытом это все можно будет располагать в одну строчку без использования вспомогательной переменной da.

Автодеск не патентовал интерфейс. Именно поэтому можно создать полную копию интерфейса (всякие шит-кады от китайских разработчиков) без нарушения авторских прав. Не запатентован Автодеском также и формат DWG (DXF). Возможно написание любых библиотек для работы с форматом, которые подцепляются к интерфейсам. Сочетание этих факторов позволяет легально создавать визуально практически неотличимые от оригинала продукты, но с другой математикой под капотом, а также с возможными проблемами, связанными с ошибками в математике этих библиотек. Кроме того возможны проблемы и с совместимостью , если автодеск, как законодатель мод, будет вводить новые фичи.

Судя по фрагменту вы устанавливаете дополнительно способ выравнивания ( "_j" "_mc") и пользовательскую ширину ( "_w" (itoa (* 0 1) )) Предлагаемый мной способ должен сделать фрагмент универсальным и независимым от среды (акад, нано) А еще лучше вместо (command ... использовать функцию (entmake ... . Но с ней нужно чутка повозиться. Старания окупятся сторицей (скорость - выше на порядок, никаких проблем с включением/отключением привязок, создание слоев одновременно с созданием элементов и т.д.)

Если в команде только снятие подсветки, то можно использовать функцию на лиспе (sssetfirst nil nil) и все. Если в составе программного комплекса, то в цикле однозначно, как предложили выше.

В лиспе как раз несложно (setq a (car (entsel))) ; Или любой другой способ получения имени объекта (setq da (entget a)) ; получение списка DXF-кодов (setq db (subst (cons 71 5) (assoc 71 da) da)) ; изменение текущего значения выравнивания на новое (5- середина по центру) в списке параметров (entmod db); обновление элемента Собственно третья строка и является прообразом внесения изменений в параметры элемента. Такой вариант предпочтительнее использования функции (command ... за счет универсальности и независимости от платформы.

Предполагаю, что некий другой хитрый пример расположения отрезков может привести к рисункам, которые нельзя публиковать. Но мой риторический вопрос был несколько о другом. Из этой справки очевидно, что отрезки могут менять длину за счет перемещения точки касания вдоль прямой, на которой лежит отрезок, но не могут "соскочить" с этой прямой. Разница в методах только в том, что в NC нет ограничений на перемещение точки вдоль прямой, а в АС есть. Какой метод лучше - чистая вкусовщина и к данному обсуждению не относится. Применение же отрицательного радиуса в NC (в АС такой вольности не допускается) приводит Здесь два белых отрезка скругляются отрицательным радиусом, превращаясь в красные отрезки и дугу между ними. Изначально дуга вычисляется верно (зеленая) - она является касательной к задающим отрезкам (белые) и расположена относительно точки пересечения отрезков по "другую" сторону от точек, в которых указывались объекты (на данной схеме я указывал их ниже точки пересечения), т.к. радиус был задан отрицательным. Но почему то дальше происходит изменение длины этой дуги и , соответственно, смещение точек касания в новое положение вне задающих отрезков (вдоль желтых направлений). Помимо нелепого изменения направления задающих прямых и само скругление перестает быть касательным к образующим. Налицо явный косяк в математической модели, то бишь в геометрии.

но не должен Ответ в виде ссылки, недоступной для большинства пользователей, не совсем корректен. Но верю, что там нет ничего непечатного. Затерминейтить ввод отрицательных чисел - это самое простое и напрашивающееся решение. Надеюсь, так и будет. ОФФ. Но остаётся риторический вопрос о качестве программирования и построения математической модели для данной операции. Каким образом получается, что задающие отрезки изменяют свое направление?

Это относится к команде FILLET. Результат не просто неожиданный, а В данном скрине изначальная пара отрезков (белые) сопряжена с положительным радиусом (синие) и таким же, но отрицательным (красные). При отрицательном радиусе задающие отрезки изменяют свое направление, чего в принципе быть не должно. Ну и криво работающие ключи консольных команд - это старинная головная боль, которая достаточно легко купируется. Необходимо отметить, что команды фаски и сопряжения, заложенные в меню, имеют лидирующий символ m (mfillet, mchamfer). Эти команды не позволяют вводить отрицательные значения, но позволяют ввести 0. В такой реализации исходная проблема имеет решение, хотя и не самое удобное. Почему нельзя изменить радиус в командной строке - непонятно. Можно только в диалоговом окне. Но и на том спасибо. UPD. mfillet не позволяет вводить отрицательные значения в диалоговом окне (позволяя ввести 0). Но возможен ввод отрицательных значений в командном режиме. С аналогичным нелепым результатом, как и для команды fillet.