Создание спецификации автоматически (Дубль2), Рассматриваются технология и ее реализация по автоматическому создани Опции

[Гость_Supermax_*]

Я тоже за модульность. Но при работе очень часто забываешь, что надо длины выравнивать и сразу считать стремишся. А уж если попросил сделать кого-то, то гарантий, что все будет по технологии - накаких. Прежде чем что-то делать, надо чтобы программа выбрасывала последовательно все вопросы по предшествующим этапам работы типа "Вы выровняли длины?" и т.п. Можно тут же кнопку вставить для выравнивания, но как вернуться потом назад?
Равнялку хоть сейчас делать можно. Ничего не мешает. Равняй что хочешь, с любыми названиями свойств. Правда если выбрал свойство, что равняться в принципе не может, надо откат назад организовывать.

Kpblc, за один раз, ровняется только одно свойство! Никаких два, три и т.д. Ткнул в тройник - выровнял длинну отходящей линии, ткнул опять в этот тройник - выровнял длинну одной стороны основной магистрали (на заказ делают с разными длинами аж до 3-х метров). Выровнял ты все, или что-то пропустил - ты и сам не можешь определить, а уж программе как?
С количеством критериев согласен.
С индексируемыми и не индексируемыми свойствами ты меня вогнал в ступор. Взяли присвоенное пользователем наименование свойства и определили его сущность. Если оно нам подходит, то читаем, что там указано и редактируем. Про какие индексы ты ведешь речь?

По поводу лежащих в нутри блоков других блоках:
Вот я беру и составляю спецификацию на теплотрассу. У меня на ней есть мертвые опоры - это блоки. В нутри них есть свои блоки - элементы мертвой опоры производителя такого-то, бетонная конструкция из арматуры, швелеров и есс-но бетона.
Подчеркиваю! Я составляю спецификацию на теплотрассу! В ней указано - мертвые опоры Д-219 8 штук. И точка. То, что в них находится оформляется в спецификации на изделие! Которое называется "Мертвая опора Д-219"
Если я для удобства работы с моделью объединил элементы в блок, а потом хочу его много раз скопировать и все это посчитать, то я должен во первых делать такие объединения корректно с точки зрения проектировщика, во вторых не забывать их взрывать, если это временная мера. Если я редактором открою такой блок и прямо в редакторе все подсчитаю, а потом умножу на количество то это будет локальная спецификация на изделие. Если такая локальность условна, то разработка слияния локальных спецификаций в глобальную элементарна. Эксель делает это в два счета, да и макрос к автокаду можно потом сделать. Но это отдельный макрос.
Давай не заморачиваться этим вопросом. и так будет ясно, что покупное, а что изделия. А открыв любое изделие считай его отдельно. Так положено.

Про создание новых атрибутов:
Деталей и сейчас уже такая гора, что просто ужас. Я считаю трассу, и тут обнаруживаю, что у меня в одной камере ФБС-ки - солиды. Везде блоки, а тут солиды, понимаешь. Хорошо думаю, как с этим бороться? Ладно думаю, возьму и выключу все блоки - выключил. На чертеже и ФБС-ки и плиты и лотки. Сразу все и узрел. Ладно думаю, выключу ка я блоки с атрибутами - выключил. Половина блоков без атрибутов!
Аудит корректности исполнения модели - отдельная песня. Поиск и исправление "накладок" очень нужная вещь. Мы ее сделаем. В ней нет ничего сложного, но это отдельный макрос. Вот там и надо создавать атрибуты и даже заменять изделия.
Наименование атрибута блока - вещь очень принципиальная. Не нарывайся на необходимость все время редактировать имена атрибутов, только потому, что у тебя зашита в программу установка на конкретное имя. Этим всю работу со смежниками можно загубить.
Еще раз повторю. Значение динамических свойств блока - это значения параметров настоящего изделия, а атрибуты блока - это значения характеристик данного графического элемента применимо к проекту или данному чертежу. Длинна, ширина, вес и даже единица измерения - свойства. Если нет их в блоке - сделать надо.

Дальше:
Беру в руки спецификацию - 4 форматки мелким шрифтом. Делались эти бумажки не давно, но уверенности, что в них отображены последние корректировки нет. Надо по новой просчитать модель. При подсчете очень много чего считать не надо, а оно тем не менее есть, там фильтр настроен был, а как? я уже не помню. Вот когда вместе с этими файлами спецификаций есть еще и файл с настройками, благодаря которым получились именно эти документы, то и секретарша все прекрасно посчитает.
Настройки - в файл. Про *.xls чуть позже.

Сообщение отредактировал Supermax - 30.9.2007, 13:13

[Гость_Supermax_*]

Я тоже за модульность. Но при работе очень часто забываешь, что надо длины выравнивать и сразу считать стремишся. А уж если попросил сделать кого-то, то гарантий, что все будет по технологии - накаких. Прежде чем что-то делать, надо чтобы программа выбрасывала последовательно все вопросы по предшествующим этапам работы типа "Вы выровняли длины?" и т.п. Можно тут же кнопку вставить для выравнивания, но как вернуться потом назад?
Равнялку хоть сейчас делать можно. Ничего не мешает. Равняй что хочешь, с любыми названиями свойств. Правда если выбрал свойство, что равняться в принципе не может, надо откат назад организовывать.

Kpblc, за один раз, ровняется только одно свойство! Никаких два, три и т.д. Ткнул в тройник - выровнял длинну отходящей линии, ткнул опять в этот тройник - выровнял длинну одной стороны основной магистрали (на заказ делают с разными длинами аж до 3-х метров). Выровнял ты все, или что-то пропустил - ты и сам не можешь определить, а уж программе как?
С количеством критериев согласен.
С индексируемыми и не индексируемыми свойствами ты меня вогнал в ступор. Взяли присвоенное пользователем наименование свойства и определили его сущность. Если оно нам подходит, то читаем, что там указано и редактируем. Про какие индексы ты ведешь речь?

По поводу лежащих в нутри блоков других блоках:
Вот я беру и составляю спецификацию на теплотрассу. У меня на ней есть мертвые опоры - это блоки. В нутри них есть свои блоки - элементы мертвой опоры производителя такого-то, бетонная конструкция из арматуры, швелеров и есс-но бетона.
Подчеркиваю! Я составляю спецификацию на теплотрассу! В ней указано - мертвые опоры Д-219 8 штук. И точка. То, что в них находится оформляется в спецификации на изделие! Которое называется "Мертвая опора Д-219"
Если я для удобства работы с моделью объединил элементы в блок, а потом хочу его много раз скопировать и все это посчитать, то я должен во первых делать такие объединения корректно с точки зрения проектировщика, во вторых не забывать их взрывать, если это временная мера. Если я редактором открою такой блок и прямо в редакторе все подсчитаю, а потом умножу на количество то это будет локальная спецификация на изделие. Если такая локальность условна, то разработка слияния локальных спецификаций в глобальную элементарна. Эксель делает это в два счета, да и макрос к автокаду можно потом сделать. Но это отдельный макрос.
Давай не заморачиваться этим вопросом. и так будет ясно, что покупное, а что изделия. А открыв любое изделие считай его отдельно. Так положено.

Про создание новых атрибутов:
Деталей и сейчас уже такая гора, что просто ужас. Я считаю трассу, и тут обнаруживаю, что у меня в одной камере ФБС-ки - солиды. Везде блоки, а тут солиды, понимаешь. Хорошо думаю, как с этим бороться? Ладно думаю, возьму и выключу все блоки - выключил. На чертеже и ФБС-ки и плиты и лотки. Сразу все и узрел. Ладно думаю, выключу ка я блоки с атрибутами - выключил. Половина блоков без атрибутов!
Аудит корректности исполнения модели - отдельная песня. Поиск и исправление "накладок" очень нужная вещь. Мы ее сделаем. В ней нет ничего сложного, но это отдельный макрос. Вот там и надо создавать атрибуты и даже заменять изделия.
Наименование атрибута блока - вещь очень принципиальная. Не нарывайся на необходимость все время редактировать имена атрибутов, только потому, что у тебя зашита в программу установка на конкретное имя. Этим всю работу со смежниками можно загубить.
Еще раз повторю. Значение динамических свойств блока - это значения параметров настоящего изделия, а атрибуты блока - это значения характеристик данного графического элемента применимо к проекту или данному чертежу. Длинна, ширина, вес и даже единица измерения - свойства. Если нет их в блоке - сделать надо.

Дальше:
Беру в руки спецификацию - 4 форматки мелким шрифтом. Делались эти бумажки не давно, но уверенности, что в них отображены последние корректировки нет. Надо по новой просчитать модель. При подсчете очень много чего считать не надо, а оно тем не менее есть, там фильтр настроен был, а как? я уже не помню. Вот когда вместе с этими файлами спецификаций есть еще и файл с настройками, благодаря которым получились именно эти документы, то и секретарша все прекрасно посчитает.
Настройки - в файл. Про *.xls чуть позже.

Сообщение отредактировал Supermax - 30.9.2007, 13:13

[kpblc]

Значится так
Как вернуть назад? А зачем, простите? Если длины "подровняли", значит, так и было надо. Хотя... поставить метку отмены - неужели трудно?
Проблема в том, что "подравнивать" можно не только плавно изменяющиеся свойства (неиндексируемые), но и изменяющиеся пошагово.
Насчет блоков "внутри других". Кто, простите, мешает сделать либо расширенные даннные, либо словари. И читать их. А в эти словари, например, засунуть такое: '(("type" . "сборочная")) или '(("type" . "покупное")) или nil. И в зависимости от того, что засунуто внутрь этого словаря, и учитывать либо как сборочную единицу, либо как покупное изделие, либо как "разбираемое до винтика". К примеру, ставишь ту же самую мертвую опору, в словаре этого блока сидит '(("type" . "сборочная")). Внутри блока опоры еще сотня описаний блоков, в каждом из которых тоже свой словарь - сборочная она или покупная, эта единица. В момент составления спецухи выдается запрос вида "учитывать состав сборочных?" и если да, то "с какой глубиной". А дальнейшая обработка уже в общем-то проблем не составит ИМХО.
Добавлено: правда, как обрабатывать сейчас уже готовую библиотеку блоков, я пока не представляю. Можно, конечно, временно перекинуть файлы в строго определенные каталоги и на основании этого их корежить, или ini-шку нарисовать, в которой и прописывать все, только муторно это. Но решаемо. Надо только алгоритм продумать.

Деталей и сейчас <...> гора <...>

Да и бог с ним, некритично. Добавить описание атрибута в блок - задача на 5-6 функций (снятие блокировки слоев, добавление атрибута в описание блока, замена свойств атрибута, обновление блока по всему файлу, восстановление состояния слоев).
Дальше, насчет параметров и атрибутов и прокладываемой между ними границы - я не очень понял. Может, дойдет.
Фильтр составления спецификации можно хранить напрямую в dwg-файле, с массой дополнительных данных. Никто этому не помешает. Укромные места в dwg есть. Я использую обычно такое, до которого пользователь добраться не может никакими силами, и которое есть всегда - пользовательский глобальный словарь. А уж что там хранить - решается по ситуации (то есть по задаче).

Сообщение отредактировал kpblc - 29.9.2007, 21:36

[Гость_Supermax_*]

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

Обнародую одно свое намерение:

Собираюсь выложить на DWG.RU прорабскую. Тоже 3D динамический блок с планами, электрической схемой, моделью, всеми техническими характеристиками, в том числе и спецификацией внутри. Целый проект в одном блоке. Берешь такой блок и ставишь на геоподоснову. Тюк – и все данные на своем месте. Тоже самое и все изделия. Если я сделал блок – изделие, я в него могу положить за ранее таблицу со спецификацией, графики, оформленные со штампами чертежи и заготовительные ведомости.
Повторяю, не надо лезть внутрь блока. Там уже все посчитано и определено.

Обработку я уже решил и написал. Осталось по мелочам доделать.

Еще раз говорю, аудит корректности - отдельная песня. Не лепи все в одну кучу.

Еще добавлю:

Бытовка прорабская на один стульчак в каком бы разделе проекта не учавствовала не перестанет быть ею. Вот если она вдруг стала на 4 стульчака, то это уже не та бытовка! Значит - количество стульчаков в прорабской - это свойство прорабской, от изменения которго меняется суть ее планировки и комплектации. Если в блоке есть такая позиция как количество стульчаков, то оно должно быть свойством. Изменение свойства приводит к изменению *Unnn, что соответствует здравому смыслу. А вот позиция по схеме - на подсчет влиять не должна, поскольку это свойство не изделия, а прихоть проектировщика. Если этот пункт стоит в атрибутах, то на *Unnn он и не влияет. Разделение четкое, что должно влиять на суть значения конструкции, а что не должно. Так в AutoDesk-е и придумали. Какого черта лопатить все свойства и сверять их друг с другом пытаясь определить одинаковые это детали или нет? Есть имя детали зависящее от одних параметров и не зависящее от других - вот и пользуйтесь. Все от чего должна зависеть суть, а значит и имя этой сути - в динамические свойства, а все, что не должно влиять на суть - в атрибуты блока.

Сообщение отредактировал Supermax - 30.9.2007, 20:10

[Гость_Supermax_*]

Все. Делаем равнялку блоков. Она равняет и больше ничего.
Потом делаем проставление номеров позиций и номеров элементов, она прописывает атрибуты и больше ничего. Даже переменных не создает с результатом. Потом с этой модели делать штук 6 разных ведомостей, для них нужны свои алгоритмы подсчета и эти данные просто не нужны.

[Гость_Supermax_*]

Вот я прикол расскажу:

Создаем плоскость.
В свойствах Edge 1, 2, 3, 4 ставим Hidden.
Жмем Enter и Esc.

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

Вот это прикол! Туда зя, а обратно - незя! Без лиспа теперь никак. Надо включать ручки всем плоскостям, через шифт снимать выделение не нужным, оставив только эту, и вот тгда ее можно хоть одну грань сделав Visible редактировать.

Правда смог и без лиспа, через Quick Slect. Указав выделить все плоскости на слое 0. Но если у меня их тысячи, тогда как?

Сообщение отредактировал Supermax - 30.9.2007, 16:49

[kpblc]

Ну а какая разница? Даже если идти по твоему пути, все равно надо делать блок с атрибутом КАТЕГОРИЯ_МАТЕРИАЛА, что тоже не факт, что будет выполнено. По-моему, есть другой вариант (кстати, лично мне более симпатичный).
Создается база данных - хоть в текстовом виде, хоть в mdb, хоть в чем. Пока непринципиально. Там хранится соответствие: имя блока - категория.
Попутно создается дополнительный лисп "внесение блока в библиотеку ПО", который помимо того, что копирует указанный блок в файл библиотеки, еще и дополняет эту таблицу. При составлении спецификации проход выполняется только по одному уровню вложенности (блоки копирования-вставки и внешние ссылки разбираются по составу). Если надо, можно выполнять и 2, и 3 уровня вложенности, и 100 - определяется это дополнительным флажком в окне установок.
Необходимость в атрибуте отпадает, и соответственно отпадают ошибки его [не]заполнения.
Насчет "равнялки" - сейчас рисую код в первом приближении. Без инсталлятора, только лисп. Сделаю - вышлю.
Плоскость - это что имеется в виду? 3DFACE? Mesh? Solid? Грань 3DSolid'a? 4 разных отрезка? Не понял вопроса и соответственно ответа тоже нет.

[Гость_Supermax_*]

По аудиту корректности:
Запускаем модуль аудита корректности:
Всплывает панель (или строка) "Выберите тип элемента" - "Примитивы" / "Блоки" / "Внешние ссылки"
Выбрали "Блоки";
Всплывает панель (или строка) "Выберите контролируемый параметр" - "Свойства" / "Атрибуты" / "Расширенные данные" / "Словари"
Выбрали "Свойства";
Всплывает панель (или строка) "У кажите имя свойства" Здесь имеется выбор - как указать "Вручную" или "По прототипу" если "По прототипу", то предлагается ткнуть в блок-образец, если "Вручную" - надо написать имя с клавиатуры.
Указали "По прототипу", ткнули в блок-прототип и в выскачившей панели с его свойствами указали на нужное нам имя.
Выскакивает предложение указать контролируемый массив;
Берем и секушей рамкой, или через фильтр, или все выделяем.
Нажимаем Enter;
Получаем список блоков в которых не найдено данное свойство и тут надо подумать делать сервис по его установке, или только позволять открывать редактор блока на данном блоке, тем самым давая возможность это свойство установить.
Что касается расширенных данных и словарей - аналогично.
Используют другие модули их или нет - для аудита одновалентно.
В дальнейшем, если модуль не находит в блоке нужное ему ... качество, он его игнорирует.

Сообщение отредактировал Supermax - 1.10.2007, 11:09

[Гость_Supermax_*]

Kpblc, я тебе на выходных письмо отправил. Если ты его получил, то VVA скинь, то, что там для всех. Или я его переправлю под VVA.

А про прикол - это такое удобство с 3Dface

Сообщение отредактировал Supermax - 1.10.2007, 11:47

[kpblc]

Не, письма не было. Может, конечно, в спам свалилось... Можешь здесь в ПМ продублировать?
P.S. Интересно, я успею сегодня сделать "ровнялку" или нет?
---
Добавлено: ПМ получил, к вечеру отпишусь.

Сообщение отредактировал kpblc - 1.10.2007, 12:40

[Гость_Supermax_*]

Вообще-то "равнялку" сделал VVA. Правда она на одно имя блока заточена, но все равно уже половина так сказать.

[kpblc]

Во! Уже начинается - что делает один, другой не знает ни сном ни духом. Дальше будет только хуже...

[Гость_Supermax_*]

Ну код та он на сайт повесил, так что можно взять за основу. Или ты гордый?

[kpblc]

У меня сайтов, извиняюсь, немеряно На каком? Я не гордый, но вроде сейчас доделал лиспы, вопрос - скрипт для инсталлера прописывать или пока так обойдемся? Ссылку на скачку с readme-шкой см.ПМ. "Выравнивалка" : см.файл _kpblc-block-dynprop-set-round и описание на него.
P.S. Твое письмо все еще в процессе осмысления.

[Гость_Azarko aka VVA_*]

"Равнялка" с доп ф-циями

Код

;;;---------------------------------------------------------------------------
;;; Округление до ближайшего "вверх"
;;;(roundUp 51 50) -> 100
(vl-load-com)
(DEFUN roundUp (numVal roundTo / remNum)
  (IF (= 0 (SETQ remNum (REM numval roundTo)))
                     numVal
                     (+ numVal (- roundTo remNum))
                 )
)
;;;---------------------------------------------------------------------------
;;; Округление до ближайшего
;;;(roundNea 51 50) -> 50
(defun roundNea (num prec)
  (* prec
     (if (minusp num)
       (fix (- (/ num prec) 0.5))
       (fix (+ (/ num prec) 0.5))
     )
  )
)
(defun GetDynamicBlockPropertyList (obj / lstProperties)
(if (and (vlax-property-available-p obj "IsDynamicBlock")
          (= (vla-get-IsDynamicBlock obj) :vlax-true)
          (setq lstProperties (vlax-safearray->list
                                           (variant-value
                                            (vla-GetDynamicBlockProperties obj)))))
  (progn
   (mapcar '(lambda (x)(list (vla-get-propertyname X)
                             (variant-value (vla-get-value X))
                             x
                             ))
           lstProperties))))
(defun GetDynamicBlockPropertyNameValue ( obj PropertyName / Plist)
  (and
  (setq PropertyName (strcase PropertyName))
  (setq Plist (GetDynamicBlockPropertyList obj))
  (setq Plist (car(vl-remove-if-not '(lambda (x)
                                   (= (strcase (car x)) PropertyName))
                Plist
                ))
        )
  )
   (cadr Plist)
  )
;;Устанавливает у динамического блока obj свойство PropertyName
;; в значение Value
;; obj - Vla-указатель дин блока (vla-object)
;; PropertyName - имя свойства (string)
;; Value - значение свойства (string)
(defun SetDynamicBlockPropertyNameAllowedValue ( obj PropertyName Value / Plist Pobj AllValueList dynCount)
  (setq PropertyName (strcase PropertyName))
  (setq Plist (GetDynamicBlockPropertyList obj))
  (setq Plist (car(vl-remove-if-not '(lambda (x)
                                   (= (strcase (car x)) PropertyName))
                Plist
                ))
        )
  (if (and Plist
           (setq Pobj (caddr Plist))
           (vlax-property-available-p Pobj 'AllowedValues)
           (setq AllValueList (mapcar 'strcase (mapcar 'vlax-variant-value (vlax-safearray->list(vlax-variant-value(vlax-get-property Pobj 'AllowedValues))))))
           (member (strcase (mip-conv-to-str Value)) AllValueList)
           )
    (progn
      (setq dynCount (vlax-Make-Variant (strcase(vl-princ-to-string Value)) vlax-vbString))
      (vla-Put-Value Pobj dynCount)
      )
    )
  )

;; PropertyName - имя свойства (string)
;; Value - значение свойства
(defun SetDynamicBlockPropertyNameValue ( obj PropertyName Value / Plist Pobj dynCount)
  (setq PropertyName (strcase PropertyName))
  (setq Plist (GetDynamicBlockPropertyList obj))
  (setq Plist (car(vl-remove-if-not '(lambda (x)
                                   (= (strcase (car x)) PropertyName))
                Plist
                ))
        )
  (if Plist
    (progn
      (setq Pobj (caddr Plist))
      (setq dynCount (vlax-Make-Variant Value vlax-vbVariant))
      (vla-Put-Value Pobj dynCount)
      )
    )
  )
(defun mip-conv-to-str (dat)
  (cond ((= (type dat) 'INT)(setq dat (itoa dat)))
         ((= (type dat) 'REAL)(setq dat (rtos dat 2 12)))
        ((null dat)(setq dat ""))
        (t (setq dat (vl-princ-to-string dat)))))


;;;Ф-ция низкого уровня
;;; Заносит в динамическое свойство SeekName блока blk значение, округленное до ближайшего "вверх"
;;; Blk - vla-object блока
;;; SeekName - имя динамического свойства
;;; RoundTo - значение округления "вверх"
(defun blk_dyn_property_align ( blk SeekName RoundTo / val newval)
  (and
    (not (vlax-erased-p blk));_не удален
    (vlax-write-enabled-p blk);_ доступен по изменению
    (setq val (GetDynamicBlockPropertyNameValue blk SeekName))
    (or (= (type val) 'REAL)(= (type val) 'INT))
    (setq newval (roundUp val RoundTo))
    (setq newval (if (= (type val) 'INT)(fix newval)(float newval)))
    (SetDynamicBlockPropertyNameValue blk SeekName newval)
    )
    )

Пример использования: Равняет свойство "Dinstance" до ближайшего 50 "вверх" (51 выровняет до 100)

Код

;Пример
(defun C:TEST ( / adoc ss lst)
(vl-load-com)
(setq adoc (vla-get-activedocument (vlax-get-acad-object)))
(vla-StartUndoMark adoc)
(if (and (setq ss (ssget  '((0 . "INSERT"))))
           (setq lst (mapcar 'vlax-ename->vla-object(vl-remove-if 'listp (mapcar 'cadr (ssnamex ss)))))
           )
    (progn
      (vla-regen adoc acactiveviewport)    
      (foreach blk lst (blk_dyn_property_align blk "Distance" 50))
      )
          
   )
(vla-EndUndoMark adoc)
(princ)
  )

Во! Уже начинается - что делает один, другой не знает ни сном ни духом. Дальше будет только хуже...

Так и будет. Надо договорится о механизме формирования библиотеки функций. Что бы не было, что Алексей в своем коде использует
kpblc-conv-to-string, я в своем mip-conv-to-str, хотя обе делают одно и то же.
И назначить ответственного за "как пройти в библиотеку".
И файлик для апробации
 super_test.dwg ( 96 килобайт ) Кол-во скачиваний: 106


Сообщение отредактировал Azarko aka VVA - 1.10.2007, 15:49

[Гость_Supermax_*]

Проверил. Работает. Даже с русскими названиями. Осталось сделать выбор имени свойства через блок-прототип, или ручной ввод.
Эх, мужики, мужики! Вы бы договорились между собой кто чего делает, а? Жалко до слез. Или вы мейлы друг друга не знаете?
Я конечно очень рад, но боюсь могут пойти непонятки в нашей группе. Два человека написали две одинаковые функции, а интерфейсик одинаковый небось получится. У одного повыше, но поуже, а у другого наоборот вот и вся разница. Да по другому, при таких маленьких необходимостях интерфейс шибко разнообразить не получится. Мне что тоже садится и писать "равнялку" по своему?, чтобы соблюсти, так сказать, баланс?
Ладно, придумал. Окна пишу я, только не сейчас - "отопительный сезон" чтоб ему не дна и не покрышки. Хорошо хоть два манитора. На одном теплотрасса, на другом тема, а тоб уже повесился наверное.

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

[Гость_Azarko aka VVA_*]

Два человека написали две одинаковые функции

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

Код

(defun blk_dyn_property_align ( blk SeekName RoundTo / val newval)
  (and
    (not (vlax-erased-p blk));_не удален
    (vlax-write-enabled-p blk);_ доступен по изменению
    (setq val (GetDynamicBlockPropertyNameValue blk SeekName))
    (or (= (type val) 'REAL)(= (type val) 'INT))
    (setq newval (roundUp val RoundTo))
    (setq newval (if (= (type val) 'INT)(fix newval)(float newval)))
    (SetDynamicBlockPropertyNameValue blk SeekName newval)
    )
    )

Осталось сделать выбор имени свойства через блок-прототип

Парочка ф-ций уже есть. Нужно увидеть Алексея ф-цию, чтобы "поровнять".

[kpblc]

Функция _kpblc-block-dynprop-set-round, расположена в файле _kpblc-block-dynprop-set-round.lsp. Описание метода вызова - там же, в комментах

[Гость_Supermax_*]

Ура! Мы на коне!
Все очень хорошо!

[Гость_Supermax_*]

Протестил твои функции.
; error: An error has occurred inside the *error* functionbad argument type:
VLA-OBJECT nil

Пришлось правда подгрузить еще
_KPBLC-LAYER-STATUS-RESTORE-BY-LIST
_KPBLC-ERROR-CATCH
Надеюсь ничего не забыл.

До выравнивания пока дело даже не дошло.

Сообщение отредактировал Supermax - 3.10.2007, 14:55

[kpblc]

Значится так. Прочти readme, там же написано было - как запускать:

Сейчас (по состоянию на 01.10.2007) ситуация такова:
- сделан универсальный загрузчик
- для установки "в режиме разработчика" надо в реестре в ветке
HKEY_LOCAL_MACHINE\Software\ прописать дополнительный раздел, назвав его
abok-ware, в нем - подключ "cad" и там строковый параметр с именем rootdir и
значением имени каталога, куда были распакованы лиспы. Как пример см.
abok.reg.
- Запустить acad.exe, желательно в отдельном профиле и загрузить файл
kpblc-loader.lsp, он сам все сделает. В дальнейшем при запуске acad'a в этом
профиле все лиспы, arx, dbx, vba и тому подобное будет грузиться автоматически
и не требовать повторного запуска.

[Гость_Supermax_*]

Ты предлагаешь лезть в реестр только мне, или всем? Это

он сам все сделает

не опасно? И что собственно делает kpblc-loader.lsp?
Ты не подумай, что я такой лентяй или профан, просто на медни я с реестром вел войну и теперь при этом слове у меня начинает дергаться левое веко.
И собственно какие еще есть режимы кроме

"в режиме разработчика"

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

В дальнейшем при запуске acad'a в этом
профиле все лиспы, arx, dbx, vba и тому подобное будет грузиться автоматически
и не требовать повторного запуска.

я признаюсь растерялся слегка.

[kpblc]

Ладно, я так понял, что надо полностью идеологию расписать прямо сейчас чтобы не было в дальнейшем всяких разных вопросов
Общая схема установки такова: инсталлятор в процессе работы в ветку HKLM\Software\abok-ware\cad прописывает путь, куда установлен весь комплекс. Также либо создается новый профиль, либо комплекс "интегрируется" в имеющиеся профили AutoCAD'a.
При первой загрузке kpblc-loader.lsp (это основной загрузочный модуль) выполняется следующее (пока так, дальше можно наращивать и сделать все что понадобится): в самое начало путей поддержки добавляются пути, куда был установлен комплекс; выполняется инициализация глобальных переменных; загрузка arx, lsp, fas, vlx, dvb-файлов. При последующих загрузках выполняется все то же самое, но без добавления путей. Учитывая, что в добавленных путях лежит файл acaddoc.lsp, он загружается сам и обеспечивает загрузку kpblc-loader.lsp.
Опять-таки, без меню будет не обойтись. Добавить потом пути поддержки меню - плевое дело. И обеспечить его загрузку. Или повторить то же самое, но с палитрами инструментов.

[Гость_Supermax_*]

Просмотрел я это loader, и вот что я скажу:
Есть, с моей точки зрения, маленькие потребности, но редкие. Есть большие, но редкие. Есть маленькие, но частые и аналогично - большие. Упорядочивание и создание стереотипов поведения целесообразно при угрозе утонуть в несостыковках и информационном дефиците. Я надеюсь что меня можно понять?
Тебя Kpblc, как программиста я очень хорошо понимаю, и этот наворот тебе конечно же необходим. НО! Есть много вещей, которые пользователь обязан делать сам и подстраиваться под не компетентных пользователей значит порождать их все больше и больше. Я это про поиски путей к файлам и прописки жестко имен папок.
Все эти оболочки - оправа к бриллианту, которым конечно является твой лисп, но если вынутый из оправы бриллиант вдруг перестает сверкать, то что это за бриллиант такой? Функция к AutoCAD-у должна быть с моей точки зрения "вещью в себе". Все служебные функции должны быть в нее встроены и для работы макроса больше ничего не должно быть.
Ты же знаешь, как сисадмины крупных контор относятся к инсталлируемым продуктам. Без них конечно не обойтись, но не палить же по воробъям из пушки.

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

Моя позиция такова: Все лиспы должны быть самодостаточны. То есть если им надо подгрузить функцию из другого файла, то (load "и т.д. Рядом с лиспом лежат файлы и если его открыли в этой директории, тон в ней и шарит. Куда ни положи - везде работает.

Сообщение отредактировал Supermax - 3.10.2007, 17:44

[kpblc]

Оболочки - не оправа, как ты выразился, а необходимые шестеренки в часовом механизме. Ты предлагаешь пользоваться китайским ноу-хау "копи-паст"? Я на это не пойду ни за какие коврижки. Код должен использоваться многократно. Это аксиома. Можешь почитать про С++ и его организацию классов.

Ты же знаешь, как сисадмины крупных контор относятся к инсталлируемым продуктам.

Знаю. Но если я вижу, куда и когда лезет софт, я спокоен. Особенно если софт в открытых кодах.

Без них конечно не обойтись, но не палить же по воробъям из пушки.

А это не из пушки и не по воробьям. Это преследование следующих целей:
- код должен легко изменяться и наращиваться, сохраняя имеющуюся функциональность
- код, как и книга, должен быть разбит на логически завершенные элементы (главы)
- в коде, как и в технической литературе, нельзя повторно впрямую копировать и вставлять текст (см., например, http://www.computerra.ru/offline/2001/420/13946/ )
Теперь последнее:

То есть если им надо подгрузить функцию из другого файла, то (load "и т.д. Рядом с лиспом лежат файлы и если его открыли в этой директории, тон в ней и шарит. Куда ни положи - везде работает.

Во-первых, нереализуемо. Из-под лиспа нереально узнать каталог, из которого лисп загружен и запущен. Из-под VBA - да, еще можно попробовать. Но дальнейшая судьба VBA неясна (на autocad.ru была тема).
Во-вторых, это показывает, что тебе пока не довелось разрабатывать сколько-нибудь крупный проект. Сейчас определение пути установки идет всего в одном месте. Стоит это переделать на твой вариант - и все, кирдык, надо проверять все файлы на предмет проверки. Или второй вариант: сначала была написана функция работы с целыми числами, и написана так, что она может возвращать как целые числа, так и числа с плавающей запятой (соответственно типы int и real). К примеру:

Код

(defun loc:testfunc(value)
(+ value 2))

В результате:
(type (loc:testfunct 2)) -> int
(type (loc:testfunct -163)) -> int
Если следом у тебя используется проверка типа

Код

(if (= (type (loc:testfunct value)) 'int)
(alert "Работа продолжается")
(alert "Тип не тот, работа прекращена"))

То достаточно value быть равным, к примеру, 4.16, и проверка выполнена не будет. Переделывать проверку на (if (= (type (loc:testfunct value)) 'real) бесполезно - достаточно value получить тип int, и проверка опять не пройдет. А весь вопрос всего в одном символе.
А теперь усложним задачу Пусть в loc:testfunct не одна строка, а, к примеру, 100-200. Не запаришься проверять и отлавливать ошибки, а потом новую версию в тысячу лиспов перекидывать?
Я достаточно ленивый человек, чтобы одну и ту же работу выполнять больше 2 раз.
Есть предложение послушать VVA - может, у него есть свои варианты по этому вопросу.
---
Добавлено: жалко, что у меня нет таланта ShaggyDoc объяснять такие вещи... Если можешь, просмотри "САПР на базе" - там все аргументированно рассказано.

Сообщение отредактировал kpblc - 3.10.2007, 21:06

[Гость_Azarko aka VVA_*]

Я согласен с Алексеем.
Если речь идет об одной команде (как часто просят на форуме), тогда можно все нужные ф-ции сделать локальными и получится самодостаточная вещь. Если таких команд уже 2 то тут уже вознивают вопросы.
По поводу прописки в реестре:
На последнем этапе пожно все файлы собрать в один fas файл и поставить (как вариант) в автозагрузку или mnl файл.

Сообщение отредактировал Azarko aka VVA - 4.10.2007, 9:53

[kpblc]

По "последнему" этапу (ну и фразочка получилась )
mnl-файл хорош, но пока-то никакого меню нет. Появится - переименовать loader.lsp в MenuName.mnl недолго
Я против попыток записи в автозагрузку (на аркаде я расписывал свои попытки, вынужден констатировать, что 100% успеха они не имели) - если делать ее лиспом. А если не лиспом, то чем? Инсталлятором? Прошу прощения, но, по-моему, это те же яйца, только в профиль. И потом, приложения, записанные в Autoload Startup Suite, загружаются во все профили, а это может оказаться ненужным или лишним в некоторых случаях.
fas-файл вещь хорошая, но исходники все равно понадобится предоставлять (поскольку продукт предполагается под GPL). Кроме того, в fas не засунешь arx, dvb и dll. Что называется, помрем делавши.

[Гость_Supermax_*]

Теперь последнее:
Цитата

То есть если им надо подгрузить функцию из другого файла, то (load "и т.д. Рядом с лиспом лежат файлы и если его открыли в этой директории, тон в ней и шарит. Куда ни положи - везде работает.

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

(progn (load (setq Kpblc_ne_prav (getfiled “Kpblc, ты не прав!” “*” “lsp” 0))) (setq Kpblc_ne_prav (vl-filename-directory Kpblc_ne_prav)))

Остальное потом напишу, когда поем.

[kpblc]

Ты не понял задачи. Запиши лисп, к примеру, такой:

Код

(defun testalert()
(alert "Ну и пускай я не прав. /kpblc/")))

Зайди в акад, загрузи этот лисп обычным _appload, а потом попробуй определить каталог, в котором был записан этот лисп. По твоей же логике пользователи будут так загружать, а не использованием getfiled или еще чего-то.

[Гость_Supermax_*]

Способов запуска макросов явно не один. Я считаю макросы приложением к AutoCAD-у и поэтому прописываю путь в файл *.cfg а не реестр Windows. Создаю там свой раздел и храню пути.

(setcfg "AppData/Kpblc_all/lsp/_kpblc---load_" Причем последнее значение всегда использую имя файла без расширения, так легче его находить.

И так 1-й и последний запуск лиспа через окно ввода заканчивается пропиской его пути в разделе AppData файла acad2006.cfg
(load (setcfg "AppData/Kpblc_all/lsp/_kpblc---load_" (getfiled "Kpblc, я делаю так!" "*" "*" 0))))

далее в строку запуска макроса конфигурации кнопки пишу:
^C^C(load (getcfg "AppData/Kpblc_all/lsp/_kpblc---load_") "Файл не найден")
И все.

Если вводить макросы через Tools\AutoLISP\Load Application... то Autocad загружает функции из этих файлов и пути к ним не сохраняет. А так - дешево и сердито. Инсталятор из одной строчки.

Сообщение отредактировал Supermax - 5.10.2007, 16:46

[Гость_Supermax_*]

Добавлю:

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