
Mитька
-
Posts
713 -
Joined
-
Last visited
-
Days Won
34
Content Type
Profiles
Forums
Downloads
Blogs
Posts posted by Mитька
-
-
В 23.06.2017 в 22:35, yum сказал:
Если что, в листе они отображаются с различимым весом. В модели и на листе принцип отображения весов разный.
А возможно как-то организованно привести отображение линий на листе к модельному виду? Чтоб линии показывались не в абсолютном значении толщины, а относительно экрана?
-
-
Я в восторге...
Интересно, где-нибудь есть внятное подробное описание всех свистелок и тонкостей при работе с Листами в этом формате..?
добавлено через 2 минуты50 минут назад, Mитька сказал:- текст в масштабах 1:5 и ниже выглядит нечитаемо толстым при текущих настройках.
Мож и такое как-то организованно лечится..?
И пока непонятно, можно ли на 20.1 играть отдельными конфигурациями слоёв для каждого пространства (самого листа и каждого из видовых экранов)... Вроде можно было как-то...
-
1 час назад, Mитька сказал:
Та же Модель, но "с порталами".
И каждый "портал" с масштабом и фильтрами.
А я уже и сам проверил. Ооооой, какая же это прелесть!...
Два минуса пока вижу:
- текст в масштабах 1:5 и ниже выглядит нечитаемо толстым при текущих настройках. Но это, полагаю в основном отрегулируется конфигурациями, масштабами самого листа и прочими соотношениями масштабов. Надо разбираться, я тут впервой, как говорится).
- сделать бы непечатаемыми границы показа блоков... А они по умолчанию стоият в "ДА" и поменять нельзя. Но эт тоже, возможно решится.
-
В 10.07.2023 в 19:14, Boroda888 сказал:
А что плохого в оформлении в листе?
Или это из серии "мы так привыкли, так наши деды делали"?
Чего-то я тогда пропустил вопрос-то...
Из серии "мы когда-то попробовали и нам не понравилось, да так и повелось" А уже через 2-3 года вся работа построена так и менять её в масштабах организации на Листы непонятно зачем никто не будет. Работа в листах в том виде, как она задумана, радикально неудобна их (Листов) разделением. Вы ж когда ремонт делаете все инструменты скорее всего выкладываете на какую-то единую поверхность, а не из разных ящиков каждый раз достаёте по новой, когда надо. А если забыли, где молоток, то открываете и смотрите в ящик по новой, а потом в следующий и т.д. Мож любители и есть, конечно, всякое бывает, но, для нас пологовно это неудобно.
В 10.07.2023 в 20:20, doctorraz сказал:Делаю все в листе, одном листе
Как и это тогда пропустил. А вот вариант "перенести Модель в один лист" - это, пожалуй, перспективная штука очень.
Та же Модель, но "с порталами".
И каждый "портал" с масштабом и фильтрами.
Или оно там так волшебно не работает (нет опыта работы с ВЭ)?
-
1
-
-
Ну да и ладно. Пересоздам. Это быстрее, чем в первый раз ваять. Да ещё и на опыте практического использования глядишь чего и поменяю...
А что не пересоздам и "руки не дойдут" - то и потеря, видимо, невелика в целом.
-
1
-
-
Мог бы просто словами написать, мол, "ручку до конца доведи".)) Быстрее бы было).
2 минуты назад, MCAD сказал:мультик
Но для общей полезности этой темы оно только лучше будет)
-
1
-
-
1 час назад, Mитька сказал:
Но старый объект, уже существующий в чертеже, будет мало того, что эту ручку содержать, она ещё и работать будет по правилам, описанным в скрипте, которого в базе уже нет.
Отсюда я делаю вывод, что каждый объект сам по себе содержит внутри все данные, что прописаны в его скрипте и прочих разделах Мастера Объектов.
Что ж, вывод неверный в итоге. Если довести действие с ручкой до конца или поменять любое из свойств объекта, он тут же эту ручку уничтожит, сверившись с базой.... Печаль.
29 минут назад, doctorraz сказал:никак
Согласен.
29 минут назад, doctorraz сказал:чаще делай бэкапы(
Только и остаётся...
-
7 минут назад, doctorraz сказал:
таблицы параметров, скрипты, формы все это хранится в базе
на чертеже минимум необходимой графики и ID для связи с базой
Тогда как объяснить корректную работу более старого объекта в чертеже?
-
Кроме, разумеется, случаев, когда реализованного механизма нет, а все процессы, которые нужно обратить - сверхсекретны...
-
Возник вопрос про базу и параметрику: а можно ли вытащить из существующего на чертеже параметрического объекта его данные в базу объектов?
Причина простая: случайно удалил последнюю версию объекта из базы. Удалил, видимо, не вчера, т.к. бэкапы системы не спасают. Осталась боле старая версия в загашниках.
Отсюда возник вопрос: а если ли механизм экстракции данных при таком раскладе? Это ж должно быть физически возможно по идее?
Почему мне так кажется:
- существует команда "Обновить стандартные объекты", т.е. синхронизировать их с базой, т.е. взять данные по объекту из базы и скопировать их.... куда? В сами объекты ж, не?
- можно провести эксперимент: взять любой объект из вашей базы, вставить на чертёж, потом открыть его в базе и убрать из скрипта объекта одну из ручек. Просто физически стереть/закомментить. Потом позакрывать всё, перезапустить программу и попытаться вставить обновленный объект в чертеж. Он вставится туда без стёртой ручки.
Но старый объект, уже существующий в чертеже, будет мало того, что эту ручку содержать, она ещё и работать будет по правилам, описанным в скрипте, которого в базе уже нет.
Отсюда я делаю вывод, что каждый объект сам по себе содержит внутри все данные, что прописаны в его скрипте и прочих разделах Мастера Объектов.
Т.е. если эти данные есть, то может можно их как-то достать..? Или перезаписать сущестующий объект в базе (с таблицами, группами и шаблонами же такое можно сделать, как нормальный системный процесс)...
Уважаемый MCAD говорит, что не получится. Но я упорно не понимаю, почему) Если есть механизм, конвертирующий набор исходников чётко структурированного содержания в конечный объект, значит все процессы в нём (кроме рандома, удаления и т.д.) по идее можно проиграть в обратном направлении, разве нет..?
-
2 часа назад, EdwardSt сказал:
Если проводить эксперименты с отладкой,
Кстати, а никто таблицы Libre Office в качестве отладчика не использовал? Инструкцию для Excel-отладчика-наны я находил в соседней теме (но либер был бы привычнее). Или мож что-то ещё можно подключить?
2 часа назад, EdwardSt сказал:Возможно, этими двумя командами хотелка и охватывается, но это предмет дополнительного осмысления.
Пока хотелка немного отошла в тень открывающихся возможностей) Я понял, что в теории могу прописать любую реакцию программы на практически любую команду или событие (vlr-реакторов-то, я смотрю, тьма разных).
А если допускать, что это реализуемо, то можно массу всяких интересных вещей наворотить в перспективе.
Ну и да, само собой, тут уже такая область, что надо аккуратненько)). Это уже не таблички.
-
-
13 часов назад, kpblc сказал:
(if (not *kpblc-vlr-doc*)
А в первый вариант реатора (который за командами следит) такого рода проверку добавить не получится?
13 часов назад, kpblc сказал:что моих знаний и умений на разобраться с причинами не хватит, так что даже и рыпаться не буду
А я в данном случае вообще имею дело с вещами, которых на 90% пока в принципе не понимаю)
добавлено через 8 минут14 часов назад, EdwardSt сказал:Просто нужно выбрать тот, который больше соответствует хотелке.
Доработать команду - нужно использовать командный реактор (который показался более универсальным)
Хотелкам -то больше соответствует первый. Но то, что он дублирует реакторы - убирает в ноль всю его полезность.
-
20 минут назад, EdwardSt сказал:
Может, все-таки попробовать работающее предложенное выше решение
Я и пробую) Просто у ни разу не опытного в ЛИСПе человека всё это занимает крайне много времени.
2 часа назад, doctorraz сказал:Имха всежэж такие вещи лучше делать не автоматом, а по кнопке..
Если есть механизм, позволяющий без ошибок сделать это всегда автоматом - не вижу смысла не попробовать сделать.
2 часа назад, doctorraz сказал:Или хотя бы не переопределять существующие а добавлять свои
Ну понятное дело, что импортом файла Конфигурации из конкретного места, а не повальной заменой всего существующего на что-то своё)
54 минуты назад, EdwardSt сказал:Может, все-таки попробовать работающее предложенное выше решение
Попробовал. Вроде работает. Породило вопросы.
А именно: (я не особо разбираюсь в терминологии, если что. Не судите строго). Посмотрев на оба варинта реакторов:
и
я вижу следующее:
- они как будто идут разными методами - один "через дверь", второй "через параметр проницаемости стен".
- первый приколен тем, что гибко настраиваемый и привязываемый вообще везде, к любой команде.
- но с хрен пойми каким дублированием в реакторах.
- второй как будто куда как менее гибкий, но защищенный сиситемной переменной.
А можно с точки зрения ЛИСП их вообще физически как-то срастить между собой: функциональность первой и перестраховку через переменную? Они "из одной материи сделаны"?
-
Мрак какой...
-
А вот в такой последовательности:
...отрабатывается только END, START игнорируется.
добавлено через 1 минутуНо допускаю, что это лично я тут где-то лажаю. Ваще легко.
-
22 часа назад, kpblc сказал:
Небольшое уточнение: в реакторах нельзя использовать командные методы (насколько я помню)
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 минут22 часа назад, kpblc сказал:Я бы пользовал реакторы (как минимум командные) при таких требованиях. ИМХО их хватить должно.
Но в целом, если купировать эти проблемы, то да, решение прям то, что надо.
-
8 часов назад, doctorraz сказал:
Дык блоки жэж не каждый секунд создаешь.. при создании устанавливай одинаковый масштаб..
Ну или масштабировать блоки не через свойства, а командой масштаб..
Эти-то способы мне известны)
8 часов назад, doctorraz сказал:Вангую ТС хочет шоб и по ctrl+shift+v тож были равные масштабы
А тут и вагновать нечего, именно это мне и хотелось.
Так-то по факту под мой запрос даже команда отдельная не очень подойдёт, т.к. требует дополнительного вызова, к сожалению.
Из решений, которые устроили бы меня мне приходит на ум только через таблички динамически привязать масштабы внутри блока друг к другу, чтобы при изменении одного из них таблица меняла оба других.
В теории как будто даже реализуемо, но вот стоит ли оно того в плане трудозатрат на создание и постоянную загрузку памяти - уже второй вопрос. Системная переменная бы решила проблему идеально.
7 часов назад, EdwardSt сказал:- для вхождений блоков - DXF-группы 41,42,43 (или соответствующие им COM-свойства)
- для определений блока - чуть больше ходов (точнее 2). Добраться до элемента типа (0 . "BLOCK_RECORD") и прочекить DXF-группу 281 (0 или 1 - одинаковые или разные масштабы)
Прикольно, что всё-таки можно их достать. Если придумать, как сделать эту механику работающей постоянно (или хотя бы с нужной периодичностью), то как решение вполне прокатит.
-
5 часов назад, EdwardSt сказал:
непонятно, что именно не подцепляется.
5 часов назад, EdwardSt сказал:Правда сходу в лоб не нашел, где измененное нанокадом свойство "одинаковый масштаб" сохраняется. Ни DXF-кодах (с помощью entget), ни в COM-свойствах (с помощью vlax-dump-object).
Вот именно то, что вы в лоб не нашли - оно и не подцепляется) Как програмно поменять то, чего не знаешь даже как называется?) *не, наверняка и не такое можно, но при некотором опыте.
"Не подцепляется" - означает, что я не знаю внутринанокадовского способа повлиять на это свойство блока иначе, чем через "Выделить все блоки и в Свойствах поменять" (это-то я и сам могу) только запрос в том, чтоб как раз этого и не делать больше никогда).
7 часов назад, doctorraz сказал:Bargtools есть команда по нормализации блоков..
Вообще непонятная фраза.
Что есть Bargtools?
-
1 минуту назад, kpblc сказал:
А с чем связано такое желание - переделать стандартные команды?
Хочется уметь возможность "привязать" к стандартным командам что-то ещё по умолчанию.
К примеру: я хочу, чтобы в любой открываемый любым способом файл по умолчанию добавлялась моя Конфигурация слоёв. Или чтобы при сохранении программа автоматом делала то-то и то-то.
Допускаю, что на современных версиях это и есть по умолчанию, но у меня 20.1 (или я просто не знаю, как это делать, не важно для ответа).
Мож ещё какие-то способы есть, кроме замены команды, мало ли.
добавлено через 0 минут6 минут назад, kpblc сказал:лично мне не удалось
Учитывая ваш опыт звучит как "невозможно в принципе")
-
Наверняка же кто-нибудь озадачивался переписыванием и переназначением стандартных команд Нанокада (Типа "Сохранить", "Новый файл", "Закрыть" и т.д.) на LISPе? Есть какие-то проверенные временем версии, чтоб заменить и спокойно забыть до поры, пока не захочется в них что-то своё добавить?
-
У всех блоков переменная "Одинаковый масштаб" автоматом выставлена в "Нет". Извне как свойство блока она не подцепляется, отсутствует как свойство (по крайней мере в версии 20.1) и повлиять на неё костылями если и можно, то я не знаю, как.
Есть ли мож системная переменная какая-то или ещё что-то, чтоб настроить этот параметр по умолчанию в "Да"?
-
Да, типа того.
42 минуты назад, MCAD сказал:Тогда пока не знаю, что предложить.
Вот и я смотрю всё-таки в сторону ЛИСПа. Как будто встроенными средствами такое хрен реализуешь...
-
1
-
Не показывает толщину линий на листе
in Общие вопросы
Posted
Вот тут не совсем понял, где такое настраивается.