EdwardSt

Согласен с таким мнением практически на все сто. В идеале выглядит правильно, что разные системы могут подключаться к некому централизованному хранилищу для отображения и возможной обработки информации из БД. И даже файл Excel с определёнными допущениями можно считать БД в чистом виде (листы=таблицы, строки=записи, столбцы=атрибуты). Но существует огромное НО! Каждый файл Excel и каждая его копия является отдельной и независимой БД. Поэтому поддержание постоянной связи с такой БД является большой головной болью (изменение имен, перемещение папок в файлах и т.д.).

Собственно, вами предложение вами и озвучено: нужно оставить так, как привыкли. А то как в рекламе "а на левой фабрике делают правые палочки (или как-то похоже)". Зачем этот баян?

Исходный файл в версии 21.0 открылся без проблем. Возможно, есть какие-то проблемы, связанные с внешними ссылками, которые не приложены. Там должны быть файлы нескольких растровых форматов и pdf-подложка.

При работе над сложным объектом возникла необходимость подгрузки данных от смежных областей в формате IFC. Была выявлена проблема с неверным определением координат точки привязки в NanoCAD 21.0 Суть кейса в следующем: 1. В пустой файл считаны две модели в IFC 2. Красненькая модель легла в какие-то невнятные координаты и выглядит как-то так Эта модель была сделана в Ревите и включала отдельно изготовленные модели коробок в собственных координатах, "посаженные" в координаты объекта. В таком виде она и экспортировалась в IFC 3. Синенькая модель лег

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

Не нужно передергивать. Речь об идеальности и вообще хорошести не идет. Очевидно, что блокнот функциями не перегружен. И хотя они используются на 99%, я отдам предпочтение 4% функций ворда. Любая САПР по определению будет перегруженной. Функциональность наращивается, ничего не выбрасывается. Но повторять противоречивый функционал (не путать с маловостребованным!) - совершенно нет необходдимости.

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

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

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

Этот случай является частным. Да еще и дублирующим "Сохранить как" А что делать, если выбран другой способ? Добавлять к свойствам что-то типа "..._усеченный" ? Или добавить кнопку с диалогом по изменению свойств? Спорно это все, и непонятно зачем. PS. Опять вспомнилось изречение профессора

Автоматический перенос атрибутивных свойств целого объекта (чертеж) на его часть (примитивы, попавшие в ПБЛОК) в исходном виде - достаточно нелогичная операция, ИМХО. Организовывать отдельный процесс по заполнению части свойств - тоже весьма спорная затея. Все-таки, результат ПБЛОК - это файл, который предполагается использовать в виде блока. Т.е. самостоятельным чертежом-документом он как бы не является. А значит и заполнение свойств (см. выше) видится излишними. Поэтому, скорее это можно считать спорной (и безальтернативной?) фичей ТАМ. PS. Вспомн

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

Без этого замечания имело бы смысл поуговаривать, попробовать переубедить, приводить аргументы... А так остается только сожалеть, что кто-то через силу вынужден называть нашу страну нашей. Желаю найти гармонию с собой и с действительностью.

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

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