EdwardSt

В данном случае, действительно, необходимо установить UCS по виду. Необходимо только помнить, что при изменении вида эти тексты начнут видоизменяться. Возможно, этот вид имело бы смысл сделать именованным, чтоб можно было к нему вернуться в любой момент.

Ну, так и подумал. Но уж больно хитро. И ручки, опять же...

Кстати, а зачем такое количество вершин полилинии? Это попытка изобразить дугу сегментами или была какая-то другая задумка? Собственно, это обилие ручек тебе и мешает. Не?

Понятно) Четвертый вагон - это не тот, который после 3-го, а тот, который перед 5-м

И все-таки

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

Ну, естественно. В примере выше у меня получилось несколько больше. Но там я специально этот момент отслеживал (начинал программировать еще на МК54, когда бились за каждый шаг программы и каждую ячейку памяти). Если отдать это пользователю на откуп, то очень быстро за маркой кабеля потребуется далее хранить данные о производителе, адресе установки и ФИО владельца. 16кб будет выбрано очень быстро.

Кстати, еще одно соображение в копилку сомнений. Размер расширенных данных ограничен 16 кб. Это на все приложения. Если дать возможность пользователю добавлять расширенные данные через оконный интерфейс, то эти 16 кб будут выбраны мгновенно или около того. Для обхода этого ограничения нужно использовать не XData, а XRecord вкупе со словарями. Что сильно повысит "заточенность" решения под конкретное приложение. От универсального подхода уходим еще дальше.

Забудешь, как пить дать...

Ну, дык, это само собой. О том даже и упоминать не стал))) Но, честно говоря, предлагать кому то делать массированно штриховку - сам от себя не ожидал!

Я имел ввиду что, не редактируется список дополнительных привязок, в отличие от основных. Может только вкл/откл целиком. ctrl+ПКМ - это один из способов динамического переназначения привязки в момент выполнения, вроде предложенного выше в интерфейсе системной переменной. Кстати, спасибо за напоминание. Знаю что есть, но запамятовал как.

Привязка - это уже обработка, т.к. происходит по специальным правилам. Т.к., для разных типов должны использоваться свои уникальные конструкции. Конечно, да. И в примере выше я показал реальные расширенные данные, которые используются сторонним приложением (кстати, уже ~15 лет как) Но достучаться до них сейчас можно только программным способом, например, используя (entget <ename> (list "*")) или через COM (vla-getXata ...).

Как уже выше отметили, можно и без СПДС Т.е., алгоритм формирования привязки к моменту указания точки следующий: 1. Сразу после запуска команды считывается текущий режим привязки (включена или нет) и собственно набор режимов. 2. Если взведена галочка (см. выше), то для некоторых команд (простановка размеров - одна из них) этот список дополняется этим списком автоматических привязок. 3. Сформированный к этому моменту окончательный список (временный по своей сути) может скопом отключаться/включаться по F3, либо редактироваться Кстати, интерфейс системной переменной удобно включить для наблюдения за изменением значения при вызове команды нанесения размеров, нажатия F3 и изменения галочек непосредственно в момент выполнения команды. Занятное видео получается. ЗЫ. Отдельное редактирование списка дополнительных привязок, похоже, не предусмотрено. Вкл/Откл только скопом.

Все это означает, что обрабатываться будут только данные одного из(!!!!!) возможных приложений - этого самого пресловутого менеджера. Это исключает универсальный подход, о чем был пост от @MCAD. Т.е., вы предлагаете создать специальное приложение (менеджер) с заранее оговоренным списком параметров (или правилом формирования такого списка). Собственно, это и реализовано в MEP и прочих. Нормальный функционал для вертикального приложения. Для платформы, которая по сути должна быть универсальной, инструментарий тоже логично создавать универсальный. А красивости, типа создания собственного классификатора свойств и способов его отображения и менеджмента оставить вертикалкам. Кстати, это сейчас так и реализовано. В том же конструкторском БИМе вновь элементу можно назначить свойства, которые будут сохраняться вместе с ним в модели, составляя его информационную часть. То, что эта тема давно теребит воображение проектировщиков, подтверждает и пост Единственное, что хотел уточнить, там было сказано Это сделано в голом АС? ,

Можно попробовать через штриховку SOLID. 1. Выбрать любым способом несколько объектов 4. Наслаждаемся пятнистым одеялом заливок и сильно сниженной производительностью при большом количестве объектов

Офф. У самурая нет цели. Есть только путь! )

Очень занятная идея - отображать (а значит делать доступным через быстрый выбор!) расширенные данные. Но реализация может быть очень хлопотной с сомнительной ценностью. Т.к., к элементу могут быть привязаны расширенные данные, относящиеся к нескольким приложениям. Причем, только эти сами приложения могут корректно интерпретировать эти данные. Вот нет уверенности, что такая задача - отображать расширенные свойства объектов, присвоенные сторонними приложениями, - реализуема в универсальном ключе. Рад был бы ошибиться. Хотя тема с универсальным маркером вольно или невольно, но явно шаг в этом направлении.

Хотелось бы уточнить, т.к. сам проверить не могу. При присвоении атрибутов происходит преобразование элемента в какой-либо объект вертикалки (труба, трасса или т.п.)? Может, есть возможность приложить файл примера с каким-либо отрезком, которому назначили атрибуты? Сама по себе идея достаточно востребованная, сам вокруг да около реализации нечто подобного ходил. Но всегда это выливалось в создание некого минивертикального приложения, в котором происходит управление такими объектами. До универсальных средств доводить не приходилось ввиду не очень понятного способа использования вне конкретной среды.

OSMODE и далее выбрать 0 или (setvar "osmode" 0)

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

Видать, раньше такой проблемы не озвучивали. Лечится она не легко, а очень легко. Простенький скрипт позволяет дать окошку любой заголовок (в данном случае использовано полное имя файла). Для полного фарша можно несколько усложнить все и посадить автоматическое обнаименование окошка в реактор открытия или сохранения файла. Пример такого реактора не так давно разбирали.

условие while - внешнее. На мой взгляд, цикл внутри for ... next i бесконечен. До проверки условия while не доходит. Но если у вас код работает (не зацикливается) и создает надписи по количеству строк, то это мое подозрение можно дальше не обсуждать. Попробуйте отказаться от индекса k вообще, как я отметил в сообщении выше. По крайней мере в той части кода, которая приведена, он никак не используется вразумительным способом. UPD. Кстати, фрагмент, приведенный @doctorraz именно так и реализован: никакой индекс дополнительно не требуется. Используется статический массив из трех элементов. UPD2 Вообще без j,k и while

это то понятно. У меня подозрение про то что увеличение i согласно коду происходит бесконечно, т.к. внутри цикла изменяется j, что сдвигает верхнюю границу. Кстати, файл эксель протетстить сейчас не могу. оцениваю только код в сообщении

Сдается мне, что Происходит изменение индекса к для каждой строки и присвоение элементам массива начиная с к-го элемента. А для вставки используется просто массив InstPoint. Не силен в VB, но выглядит крайне подозрительно. Считаю, что индекс к здесь просто лишний InstPoint(0)= x InstPoint(1)= y InstPoint(y)= 0 - и все! Кроме того изменение индекса j внутри цикла "отодвигает" верхнюю границу индекса i. Это действительно так задумывалось? На мой взгляд, это может привести к бесконечному циклу. Код сам реально рабочий? (сейчас нет возможности проверить )

В примере выше работа не с проксями, а при запущенном СПДС. А "лучшесть" инструмента - это очень неоднозначная категория и, ессно, индивидуальная. Лисп откровенно слаб в условиях обработки событий среды и реализации всяких форм и окошек. Но, как по мне, так управление через DXF-коды - это самая эффективная работа с примитивами . Ну и совместимость - это самый большой плюс лиспа. Остальным средствам очень далеко до него. Что касается скорости выполнения, то тоже не все однозначно (сразу отбросим из рассмотрения функцию command). Думаю, что все-таки отталкиваться нужно от задачи и время соизмерять со скоростью реакции пользователя. Выполнение команды за 0,01 секунды - это действительно существенно круче, чем за 0,5 сек? Не думаю. Кстати, неоднократно приводились сравнения типа .NET быстрее лиспа и т.п. Это на каких задачах исследовалось? Хотелось бы подробностей. Зы. Давненько занимаюсь программированием. Доводилось использовать совершенно разные по идеологии языки и средства (фортран, паскаль, разные Си-клоны, ассемблер, пролог) - для каждого средства есть своя ниша. Плюсы - это самое универсальное и мощное средство. Но оно в том числе подтверждает выстраданную истину: специализированное средство практически всегда превосходит универсальное в своей вотчине. Поэтому лисп для кадов живее всех живых. добавлено через 7 минут аналогично. В задаче выше просто было условие использования конкретного объекта, потому пришлось "снизойти" до СПДС)