Jump to content

Mитька

Пользователи
  • Posts

    713
  • Joined

  • Last visited

  • Days Won

    34

Posts posted by Mитька

  1. В 23.06.2017 в 22:35, yum сказал:

    Если что, в листе они отображаются с различимым весом. В модели и на листе принцип отображения весов разный.

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

  2. 28 минут назад, doctorraz сказал:

    И удивляешься, что видимостей рамок разных подрезок аж три состояния)))

     

    image.thumb.png.323dcff4869a193c4f3a2dc423ed2b29.png

    Пока не спасает. И вижу, и печатается...

     

    Хотя эту тему, наверное, не тут надо уже обсуждать...

  3. Я в восторге...

    Интересно, где-нибудь есть внятное подробное описание всех свистелок и тонкостей при работе с Листами в этом формате..? :blink:

    добавлено через 2 минуты
    50 минут назад, Mитька сказал:

    - текст в масштабах 1:5 и ниже выглядит нечитаемо толстым при текущих настройках.

    Мож и такое как-то организованно лечится..? 

     

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

  4. 1 час назад, Mитька сказал:

    Та же Модель, но "с порталами".:wub: И каждый "портал" с масштабом и фильтрами. :wub::wub:

    А я уже и сам проверил. Ооооой, какая же это прелесть!...

    Два минуса пока вижу:

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

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

  5. В 10.07.2023 в 19:14, Boroda888 сказал:

    А что плохого в оформлении в листе?

    Или это из серии "мы так привыкли, так наши деды делали"?:D

    Чего-то я тогда пропустил вопрос-то...

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

     

    В 10.07.2023 в 20:20, doctorraz сказал:

    Делаю все в листе, одном листе

    Как и это тогда пропустил. А вот вариант "перенести Модель в один лист" - это, пожалуй, перспективная штука очень.

    Та же Модель, но "с порталами".:wub: И каждый "портал" с масштабом и фильтрами. :wub::wub: 

    Или оно там так волшебно не работает (нет опыта работы с ВЭ)?

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

    А что не пересоздам и "руки не дойдут" - то и потеря, видимо, невелика в целом.

    • Like 1
  7. 1 час назад, Mитька сказал:

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

    Отсюда я делаю вывод, что каждый объект сам по себе содержит внутри все данные, что прописаны в его скрипте  и прочих разделах Мастера Объектов. 

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

    29 минут назад, doctorraz сказал:

    никак

    Согласен.

    29 минут назад, doctorraz сказал:

    чаще делай бэкапы(

    Только и остаётся...

  8. 7 минут назад, doctorraz сказал:

    таблицы параметров, скрипты, формы все это хранится в базе

    на чертеже минимум необходимой графики и ID для связи с базой

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

  9. Возник вопрос про базу и параметрику: а можно ли вытащить из существующего на чертеже параметрического объекта его данные в базу объектов?

    Причина простая: случайно удалил последнюю версию объекта из базы. Удалил, видимо, не вчера, т.к. бэкапы системы не спасают. Осталась боле старая версия в загашниках.

    Отсюда возник вопрос: а если ли механизм экстракции данных при таком раскладе? Это ж должно быть физически возможно по идее?

    Почему мне так кажется: 

    - существует команда "Обновить стандартные объекты", т.е. синхронизировать их с базой, т.е. взять данные по объекту из базы и скопировать их.... куда? В сами объекты ж, не?

    - можно провести эксперимент: взять любой объект из вашей базы, вставить на чертёж, потом открыть его в базе и убрать из скрипта объекта одну из ручек. Просто физически стереть/закомментить. Потом позакрывать всё, перезапустить программу и попытаться вставить обновленный объект в чертеж. Он вставится туда без стёртой ручки.

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

    Отсюда я делаю вывод, что каждый объект сам по себе содержит внутри все данные, что прописаны в его скрипте  и прочих разделах Мастера Объектов. 

     

    Т.е. если эти данные есть, то может можно их как-то достать..? Или перезаписать сущестующий объект в базе (с таблицами, группами и шаблонами же такое можно сделать, как нормальный системный процесс)...

     

    Уважаемый MCAD говорит, что не получится. Но я упорно не понимаю, почему) Если есть механизм, конвертирующий набор исходников чётко структурированного содержания в конечный объект, значит все процессы в нём (кроме рандома, удаления и т.д.) по идее можно проиграть в обратном направлении, разве нет..?

     

  10. 2 часа назад, EdwardSt сказал:

    Если проводить эксперименты с отладкой,

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

     

    2 часа назад, EdwardSt сказал:

    Возможно, этими двумя командами хотелка и охватывается, но это предмет дополнительного осмысления.

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

    А если допускать, что это реализуемо, то можно массу всяких интересных вещей наворотить в перспективе.

    Ну и да, само собой, тут уже такая область, что надо аккуратненько)). Это уже не таблички.

  11. 13 часов назад, kpblc сказал:
    (if (not *kpblc-vlr-doc*)

    А в первый вариант реатора (который за командами следит) такого рода проверку добавить не получится?

    13 часов назад, kpblc сказал:

    что моих знаний и умений на разобраться с причинами не хватит, так что даже и рыпаться не буду

    А я в данном случае вообще имею дело с вещами, которых на 90% пока в принципе не понимаю)

    добавлено через 8 минут
    14 часов назад, EdwardSt сказал:

    Просто нужно выбрать тот, который больше соответствует хотелке.

    Доработать команду - нужно использовать командный реактор (который показался более универсальным)

    Хотелкам -то больше соответствует первый. Но то, что он дублирует реакторы - убирает в ноль всю его полезность.

  12. 20 минут назад, EdwardSt сказал:

    Может, все-таки попробовать работающее предложенное выше решение 

    Я и пробую) Просто у ни разу не опытного в ЛИСПе человека всё это занимает крайне много времени.

     

    2 часа назад, doctorraz сказал:

    Имха всежэж такие вещи лучше делать не автоматом, а по кнопке..

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

    2 часа назад, doctorraz сказал:

    Или хотя бы не переопределять существующие а добавлять свои

    Ну понятное дело, что импортом файла Конфигурации из конкретного места, а не повальной заменой всего существующего на что-то своё)

    54 минуты назад, EdwardSt сказал:

    Может, все-таки попробовать работающее предложенное выше решение 

    Попробовал. Вроде работает. Породило вопросы.

    А именно: (я не особо разбираюсь в терминологии, если что. Не судите строго). Посмотрев на оба варинта реакторов:

    image.png.1bb7b86e97ab80a1d6719a630ccf1329.png

    и

    image.png.1e2f75ed6984f4f3df9c28f4b8b7f6a6.png

    я вижу следующее: 

    - они как будто идут разными методами - один "через дверь", второй "через параметр проницаемости стен".

    - первый приколен тем, что гибко настраиваемый и привязываемый вообще везде, к любой команде.

    - но с хрен пойми каким дублированием в реакторах.

    - второй как будто куда как менее гибкий, но защищенный сиситемной переменной.

     

    А можно с точки зрения ЛИСП их вообще физически как-то срастить между собой: функциональность первой и перестраховку через переменную? Они "из одной материи сделаны"?

     

  13. 22 часа назад, kpblc сказал:

    Небольшое уточнение: в реакторах нельзя использовать командные методы (насколько я помню)

    1. Если я вас правильно понял, то можно.

    image.thumb.png.d36d837ea2d2bafa01a48cfeacc74201.png

    Т.е. на выходе в новом файле мы получаем, что хотим - линию, вызванную командой.

     

    2. Но. Как только команд становится более одной, реактор начинает выполняться минимум по 3 раза:

    image.thumb.png.3e451eb14ce33fb8d90fed4b10bf3f9b.png

     

    И чем больше строк в реакторе, тем больше он его гоняет туда сюда:

    image.thumb.png.47d91e153a200685e6e0d0fb964b6fec.png

     

    Но как я понял из соседнего поста (https://forum.nanocad.ru/index.php?/topic/28231-vypolnit-lisp-pri-otkrytii-fayla-kak/&do=findComment&comment=126875), "размножение" реактора связано не с использованием команд, а с чем-то ещё.

    UPD: да, не от кол-ва элеменитов зависит. С чистого нанокада 1 линия сразу же задвоилась.

     

    Т.к. если как минимум в рамках той же сессии Нанокада заменить выше означенные 5 линий на вот такое:

    image.png.26e5b76720a86f453b8e5cb7f96893de.png

     

    ...то alert сработает раз 10 последовательно.

     

    3. На конструкцию с командой CLOSE программа почему-то не реагирует вообще, хоть в одну команду её с "newdocument" (как сделано у вас изначально), хоть разделяй (хотя мож тут я что-то неверно делаю):

    image.png.6794a0d8405db1df183db684cd59f4ce.png

    В моём понимании ПЕРЕД срабатыванием команды CLOSE в этом случае должен вылезти alert. Но его нет.

     

    добавлено через 0 минут
    22 часа назад, kpblc сказал:

    Я бы пользовал реакторы (как минимум командные) при таких требованиях. ИМХО их хватить должно.

    Но в целом, если купировать эти проблемы, то да, решение прям то, что надо.

     

     

  14. 8 часов назад, doctorraz сказал:

    Дык блоки жэж не каждый секунд создаешь..  при создании устанавливай одинаковый масштаб..

    Ну или масштабировать блоки не через свойства, а командой масштаб..

    Эти-то способы мне известны)

    8 часов назад, doctorraz сказал:

    Вангую ТС хочет шоб и по ctrl+shift+v тож были равные масштабы

    А тут и вагновать нечего, именно это мне и хотелось.

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

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

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

    7 часов назад, EdwardSt сказал:
    • для вхождений блоков - DXF-группы 41,42,43 (или соответствующие им COM-свойства)
    • для определений блока - чуть больше ходов (точнее 2). Добраться до элемента типа (0 . "BLOCK_RECORD") и прочекить DXF-группу 281 (0 или 1 - одинаковые или разные масштабы) 

    Прикольно, что всё-таки можно их достать. Если придумать, как сделать эту механику работающей постоянно (или хотя бы с нужной периодичностью), то как решение вполне прокатит.

  15. 5 часов назад, EdwardSt сказал:

    непонятно, что именно не подцепляется.

    5 часов назад, EdwardSt сказал:

    Правда сходу в лоб не нашел, где измененное нанокадом свойство "одинаковый масштаб" сохраняется. Ни DXF-кодах (с помощью entget), ни в COM-свойствах (с помощью vlax-dump-object).

    Вот именно то, что вы в лоб не нашли - оно и не подцепляется) Как програмно поменять то, чего не знаешь даже как называется?) *не, наверняка и не такое можно, но при некотором опыте.

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

    7 часов назад, doctorraz сказал:

    Bargtools есть команда по нормализации блоков..

    Вообще непонятная фраза. :wacko:Что есть Bargtools?

  16. 1 минуту назад, kpblc сказал:

    А с чем связано такое желание - переделать стандартные команды?

    Хочется уметь возможность "привязать" к стандартным командам что-то ещё по умолчанию.

    К примеру: я хочу, чтобы в любой открываемый любым способом файл по умолчанию добавлялась моя Конфигурация слоёв. Или чтобы при сохранении программа автоматом делала то-то и то-то.

    Допускаю, что на современных версиях это и есть по умолчанию, но у меня 20.1 (или я просто не знаю, как это делать, не важно для ответа).

    Мож ещё какие-то способы есть, кроме замены команды, мало ли.

    добавлено через 0 минут
    6 минут назад, kpblc сказал:

    лично мне не удалось

    Учитывая ваш опыт звучит как "невозможно в принципе")

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

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

    Есть ли мож системная переменная какая-то или ещё что-то, чтоб настроить этот параметр по умолчанию в "Да"?

    image.png.10d7552ffef64eb9f0ab8cffbf603af0.png

×
×
  • Create New...