Mитька

Вот тут не совсем понял, где такое настраивается.

А возможно как-то организованно привести отображение линий на листе к модельному виду? Чтоб линии показывались не в абсолютном значении толщины, а относительно экрана?

Пока не спасает. И вижу, и печатается... Хотя эту тему, наверное, не тут надо уже обсуждать...

Я в восторге... Интересно, где-нибудь есть внятное подробное описание всех свистелок и тонкостей при работе с Листами в этом формате..? добавлено через 2 минуты Мож и такое как-то организованно лечится..? И пока непонятно, можно ли на 20.1 играть отдельными конфигурациями слоёв для каждого пространства (самого листа и каждого из видовых экранов)... Вроде можно было как-то...

А я уже и сам проверил. Ооооой, какая же это прелесть!... Два минуса пока вижу: - текст в масштабах 1:5 и ниже выглядит нечитаемо толстым при текущих настройках. Но это, полагаю в основном отрегулируется конфигурациями, масштабами самого листа и прочими соотношениями масштабов. Надо разбираться, я тут впервой, как говорится). - сделать бы непечатаемыми границы показа блоков... А они по умолчанию стоият в "ДА" и поменять нельзя. Но эт тоже, возможно решится.

Чего-то я тогда пропустил вопрос-то... Из серии "мы когда-то попробовали и нам не понравилось, да так и повелось" А уже через 2-3 года вся работа построена так и менять её в масштабах организации на Листы непонятно зачем никто не будет. Работа в листах в том виде, как она задумана, радикально неудобна их (Листов) разделением. Вы ж когда ремонт делаете все инструменты скорее всего выкладываете на какую-то единую поверхность, а не из разных ящиков каждый раз достаёте по новой, когда надо. А если забыли, где молоток, то открываете и смотрите в ящик по новой, а потом в следующий и т.д. Мож любители и есть, конечно, всякое бывает, но, для нас пологовно это неудобно. Как и это тогда пропустил. А вот вариант "перенести Модель в один лист" - это, пожалуй, перспективная штука очень. Та же Модель, но "с порталами". И каждый "портал" с масштабом и фильтрами. Или оно там так волшебно не работает (нет опыта работы с ВЭ)?

Ну да и ладно. Пересоздам. Это быстрее, чем в первый раз ваять. Да ещё и на опыте практического использования глядишь чего и поменяю... А что не пересоздам и "руки не дойдут" - то и потеря, видимо, невелика в целом.

Мог бы просто словами написать, мол, "ручку до конца доведи".)) Быстрее бы было). Но для общей полезности этой темы оно только лучше будет)

Что ж, вывод неверный в итоге. Если довести действие с ручкой до конца или поменять любое из свойств объекта, он тут же эту ручку уничтожит, сверившись с базой.... Печаль. Согласен. Только и остаётся...

Тогда как объяснить корректную работу более старого объекта в чертеже?

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

Возник вопрос про базу и параметрику: а можно ли вытащить из существующего на чертеже параметрического объекта его данные в базу объектов? Причина простая: случайно удалил последнюю версию объекта из базы. Удалил, видимо, не вчера, т.к. бэкапы системы не спасают. Осталась боле старая версия в загашниках. Отсюда возник вопрос: а если ли механизм экстракции данных при таком раскладе? Это ж должно быть физически возможно по идее? Почему мне так кажется: - существует команда "Обновить стандартные объекты", т.е. синхронизировать их с базой, т.е. взять данные по объекту из базы и скопировать их.... куда? В сами объекты ж, не? - можно провести эксперимент: взять любой объект из вашей базы, вставить на чертёж, потом открыть его в базе и убрать из скрипта объекта одну из ручек. Просто физически стереть/закомментить. Потом позакрывать всё, перезапустить программу и попытаться вставить обновленный объект в чертеж. Он вставится туда без стёртой ручки. Но старый объект, уже существующий в чертеже, будет мало того, что эту ручку содержать, она ещё и работать будет по правилам, описанным в скрипте, которого в базе уже нет. Отсюда я делаю вывод, что каждый объект сам по себе содержит внутри все данные, что прописаны в его скрипте и прочих разделах Мастера Объектов. Т.е. если эти данные есть, то может можно их как-то достать..? Или перезаписать сущестующий объект в базе (с таблицами, группами и шаблонами же такое можно сделать, как нормальный системный процесс)... Уважаемый MCAD говорит, что не получится. Но я упорно не понимаю, почему) Если есть механизм, конвертирующий набор исходников чётко структурированного содержания в конечный объект, значит все процессы в нём (кроме рандома, удаления и т.д.) по идее можно проиграть в обратном направлении, разве нет..?

Кстати, а никто таблицы Libre Office в качестве отладчика не использовал? Инструкцию для Excel-отладчика-наны я находил в соседней теме (но либер был бы привычнее). Или мож что-то ещё можно подключить? Пока хотелка немного отошла в тень открывающихся возможностей) Я понял, что в теории могу прописать любую реакцию программы на практически любую команду или событие (vlr-реакторов-то, я смотрю, тьма разных). А если допускать, что это реализуемо, то можно массу всяких интересных вещей наворотить в перспективе. Ну и да, само собой, тут уже такая область, что надо аккуратненько)). Это уже не таблички.

Первые полчаса работает прекрасно) Оооох, это какую же это автоматику внутричертёжную можно с этим наворотить....

А в первый вариант реатора (который за командами следит) такого рода проверку добавить не получится? А я в данном случае вообще имею дело с вещами, которых на 90% пока в принципе не понимаю) добавлено через 8 минут Хотелкам -то больше соответствует первый. Но то, что он дублирует реакторы - убирает в ноль всю его полезность.

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

Мрак какой...

А вот в такой последовательности: ...отрабатывается только END, START игнорируется. добавлено через 1 минуту Но допускаю, что это лично я тут где-то лажаю. Ваще легко.

1. Если я вас правильно понял, то можно. Т.е. на выходе в новом файле мы получаем, что хотим - линию, вызванную командой. 2. Но. Как только команд становится более одной, реактор начинает выполняться минимум по 3 раза: И чем больше строк в реакторе, тем больше он его гоняет туда сюда: Но как я понял из соседнего поста (https://forum.nanocad.ru/index.php?/topic/28231-vypolnit-lisp-pri-otkrytii-fayla-kak/&do=findComment&comment=126875), "размножение" реактора связано не с использованием команд, а с чем-то ещё. UPD: да, не от кол-ва элеменитов зависит. С чистого нанокада 1 линия сразу же задвоилась. Т.к. если как минимум в рамках той же сессии Нанокада заменить выше означенные 5 линий на вот такое: ...то alert сработает раз 10 последовательно. 3. На конструкцию с командой CLOSE программа почему-то не реагирует вообще, хоть в одну команду её с "newdocument" (как сделано у вас изначально), хоть разделяй (хотя мож тут я что-то неверно делаю): В моём понимании ПЕРЕД срабатыванием команды CLOSE в этом случае должен вылезти alert. Но его нет. добавлено через 0 минут Но в целом, если купировать эти проблемы, то да, решение прям то, что надо.

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

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

То, для чего я спрашивал про параметры и зависимости, в этом случае реализовано через Эксель. Я, задавая вопрос, такого варианта реализации в голове не держал вообще. Потому и говорю, что - да, это рабочая схема, но по факту меня вряд ли устроит в итоге, потому и пишу про таблички (от содержимого её ячеек же тож можно зависимость подцеплять, если хочется при необходимости). Замени "первая строка выноски" на "именованная ячейка таблицы" и с точки зрения LISP-программы получишь ровно тот же механизм экстракции данных.

Хочется уметь возможность "привязать" к стандартным командам что-то ещё по умолчанию. К примеру: я хочу, чтобы в любой открываемый любым способом файл по умолчанию добавлялась моя Конфигурация слоёв. Или чтобы при сохранении программа автоматом делала то-то и то-то. Допускаю, что на современных версиях это и есть по умолчанию, но у меня 20.1 (или я просто не знаю, как это делать, не важно для ответа). Мож ещё какие-то способы есть, кроме замены команды, мало ли. добавлено через 0 минут Учитывая ваш опыт звучит как "невозможно в принципе")

Наверняка же кто-нибудь озадачивался переписыванием и переназначением стандартных команд Нанокада (Типа "Сохранить", "Новый файл", "Закрыть" и т.д.) на LISPе? Есть какие-то проверенные временем версии, чтоб заменить и спокойно забыть до поры, пока не захочется в них что-то своё добавить?

У всех блоков переменная "Одинаковый масштаб" автоматом выставлена в "Нет". Извне как свойство блока она не подцепляется, отсутствует как свойство (по крайней мере в версии 20.1) и повлиять на неё костылями если и можно, то я не знаю, как. Есть ли мож системная переменная какая-то или ещё что-то, чтоб настроить этот параметр по умолчанию в "Да"?