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

[Гость_Supermax_*]

Изменил ТЗ! Оно стало более точным.

[Гость_Supermax_*]

Изменил ТЗ! Оно стало более точным.

[Гость_Supermax_*]

Я немного пословоблудю.
Да простят меня хозяева этого сайта, но видимо без рассказа о своей фирме и том, что я делаю просто никак не обойтись. Я себя оболью клеем и посыплю перьями, чтобы не сочли это за рекламу, но суть своей деятельности и то, что следует за этим, придется открыть.
И так: Как называется моя фирма не суть важно, хотя кому надо уже знают. Занимается она «Виртуальным строительством» то есть, по готовым проектам строим в компьютере «Модель тела» и «Модель действий». На основе этих двух моделей создается потом подрядчиками ПОС и ППР. Когда на стройке 15 субподрядчиков – очень трудно сделать так, чтобы они не бились лбами друг о друга.
Чтобы строить «муравейником» надо все очень тщательно спланировать и проверить попутно проект, на предмет «хомутов» проектировщиков. Сделать резервы по снабжению, выработать регламенты, технологические карты составить (в том числе и сводные) и т.д. и т.п.
Модель здания к примеру, логически разделена на этапы строительства и когда модель готова, с нее очень удобно получать такую информацию как затраты на такой-то этап, или очень быстро перепланировать снабжение. Форс-мажоры – это можно сказать норма на строительном участке и скорость их решения и скорость адаптации к существующей ситуации определяет размер финансовых потерь от простоев, перерасходов и пр. не приятных последствий.
Существующие способы планирования можно описать очень просто. Суем палец в чернильницу и проводим на графике полосы, ковыряясь чистым пальцем в носу. Даже если графики составлены очень скрупулезно, то все равно они и рядом не лежали с пооперационным планированием и нормировками на эти виды операций. И про такое явление как саботаж не забыто. И на эту напасть есть управа. Про социальную психологию тоже не забыто. Мотивирование труда очень сильно влияет на технологию производства и управления, а уж на финансирование как влияет – сказать страшно. Многое, что есть рассказать, да влом стучать по клаве.
Так вот для меня самое главное это этап строительства и уж на его фоне я рассматриваю отдельные инженерные системы и строительные объемы. Конечно, иногда и про все сразу спрашивают, но гораздо реже, чем в частности.
Проектирование надо развивать таким образом, чтобы это действо не сдыхало, как только вышло за порог проектной организации, а продолжало приносить пользу и на строительном участке.
Переход к 3D моделированию и применению при этом «виртуальных изделий» дает возможность прямо на строительном участке крутить модель объекта, измерять его, изменять, создавать новые ведомости закупочных элементов, вносить изменения и быстро их пересчитывать.
Вот по этому я и не согласен с концепцией элементных баз. Сама модель должна быть такой базой.
Для простого проектировщика наружных сетей, конечно все это слишком глобально, но решение этой глобальной задачи (а мы ее уже почти решили, теоретически) вполне подойдет для его мелкособственнических интересов.

[kpblc]

Пока дите спит, попробую ответить сразу и на ТЗ, и на все остальное.
> #361: См.ПМ
> #393: Сильно смахивает на PDM-систему...
> #355:
Я б делал все же модульную систему, аналогичную ruCAD или CADWare (хотя в этом смысле они близнецы). То есть рисуется сотня лиспов, каждый из которых делает одну часть работы, а потом они объединяются. Как пример можешь посмотреть http://dwg.ru/forum/viewtopic.php?t=15926&start=28 - там просто библиотечные функции забиты внутрь одной.
Функция нумер раз:
1. Не оспаривается.
2. Я бы сделал конт.меню. Сначала указываются неиндесируемые свойства, следом - индексируемые.
3. Если в п.2 было выбрано неиндескируемое свойство, то запрос значения округления. Для индексируемого шаг пропускается.
4. Критериев округления несколько: в "+", в "-", "к ближайшему" и "не изменять" - для неиндексируемых свойств. Для индексируемых: "оставить как есть" или "установить ближайшее к ..."
5 и дальше. Не оспаривается.
Вопрос только один: что делать с объектами таких же блоков, лежащих внутри других блоков или внешних ссылок (ессно, что эти "другие" блоки попали в набор)?
Функция нумер два:
предлагаю просто при необходимости создавать или модифицировать новый атрибут внутри блока: "POS" - для номера позиции; "MATERIAL" - для обозначения материала (хотя, если уже есть дин.свойство аналогичное, неочевидна необходимость этого, может, из дин.свойства брать?) ну и тому подобное. То есть вопросы по пп.1-3.
Пп.4-7 - проще сделать dcl-окно динамически, чем заморачиваться.
Дальнейшее не очень понял. Но вот зачем хранить в памяти...
Добавлю: может, проще будет делать выноски программно?
P.S. Смотрю на xls как баран на новые ворота, ничего не понмаю Думаю, что пройдет, и я до всего допетрю

[Гость_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)))

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