Во-первых, мы должны уяснить себе что такое "позиция". Мое мнение на этот счет следующее:
Цифра в кружочке обозначает позицию в спецификации и в атрибуте написано (см. блок ФБС) "ПОЗИЦИЯ_В_СПЕЦИФИКАЦИИ".
В сецификации конечно можно по разному расставлять объекты по позициям, НО! На плане чертежа, элементы с одной и той же позицией, разбросаны по всему листу и говорить о какой-то ориентации на геометрическое положение, с моей точки зрения - не логично.
Количество вложенных блоков можно рассматривать только как некое свойство конструктивной насыщенности, от которого суть объекта не меняется. Вот к примеру автомобиль - модель создана не из одного блока, а там их целая гора, но тем не менее этот автомобиль имеет название ЗИЛ-130, к примеру. Ему на плане определено место, другому автомобилю - другое, разве кто-нибудь определяет место по насыщенности объекта? Вот если в атрибуте "КАТЕГОРИЯ_МАТЕРИАЛА" указано "Грузовые автомобили", то все "Грузовые автомобили" должны быть сгруппированы, а "Легковые автомобили" в свою кучу сложены. К какой группе ты приписал этот блок, в такой он и окажется не смотря на то, что он просто точка. Да, да - точка. И такие блоки бывают с атрибутами и свойствами. Свойства есть, а грфики - одна только точка.
Имен у блока, как мы уже знаем - 2. Первое является эффективным, второе - подвид этой особи, только с отклонениями в развитии. Я имею в виду *Unnn. Ясен пень, надо с начала выудить основной вид, а затем шерстить его подвиды. Чтобы в спецификации получилось "
поз. 1 эл-ты 1-6 Труба ДУ-150 L=3000 мм. - 6шт.
поз. 2 эл-ты 7-12 Труба ДУ-150 L=2500 мм. - 6шт.
и т.д.

Труба ДУ-150 - это эффективное имя или значение атрибута "НАИМЕНОВАНИЕ_ИЗДЕЛИЯ".
эл-ты 1-6 - это *Unnn с этим эффективным именем, но с одинаковой длинной L=3000 мм.
поз. 1 - это все элементы с одинаковой длинной (в частности с 1-го по 6-ой).

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

В общем вся эта нумерация уперается в основную тему и пока мы ее не начнем НОРМАЛЬНО гасить - ничего путного не получится.
Для VVA могу сказать только одно - есть 3000р - могу дать. Надо все как следует еще раз проанализировать и бери себе что нибудь на 3000р. и делай.
Я лично пока застрял на создании набора для обработки.
Все уперается здесь в работу с внешними ссылками. Без них я не могу. Либо надо AutoDesk дожимать, чтобы -refedit починили, либо сбрасывать модель в соседний файл и там превращать в единое целое, либо ПСК пересчитывать - не знаю.
Если подскажете как мне обойти эту проблему, но чтобы потом можно было вернуться и доделать с сылками - буду очень благодарен.

А я еще раз повторяю - что надо фильтровать атрибуты и свойства - что является значимым для спецификации, а что - нет. Позиция, кстати, совершенно необязательно проставляется как "число в кружке". Она может (и зачастую так и делается) проставляться как выноска. Если у тебя есть возможность, скачай или возьми демку того же MechaniCS, весьма расширяет кругозор

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

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

Для выравнивания:


1. При запуске макроса следует запрос «укажите блок образец» указав на любой подходящий блок видим список его свойств.
2. На запрос «укажите свойство длинны» - указываем свойство
3. На запрос «укажите размер округления в мм.» - указываем цифрами скажем 50
4. На запрос «укажите критерий округления + или &» Указываем + если хотим только в плюс (даже если будет длинна 10000.01 – округляем до 10060.00) если хотим обычно, то &.
5. На запрос «Все или Указать» - указываем скажем У (выбор секущей рамкой)
6. Создаем набор секущей или не секущей рамкой с возможностью многократности.
7. Нажимаем ОК и макрос выравнивает длины.

Можно зациклить этот процесс и каждый раз будет запрос «Выровнять следующую позицию?» в случае положительного решения повторяется все с пункта №1, а если больше равнять не надо – переходим к позиционированию.

Для маркировки и позиционирования:

1. При запуске макроса следует запрос «укажите блок образец». Пользователь указывает на любой подходящий блок. Макрос должен развернуть панель со списком атрибутов и свойств этого блока.
2. С верху панели над окном или в командной строке должна гореть надпись «укажите заполняемый атрибут номера» - указываем атрибут. Выбора через Ctrl или Shift - нет. Нажимаем ОК.
3. С верху панели над окном или в командной строке должна появится надпись «укажите заполняемый атрибут позиции» - указываем атрибут. Нажимаем ОК.
4. С верху панели над окном или в командной строке должна появится надпись «укажите атрибут категории материала» - указываем атрибут. Нажимаем ОК.
5. С верху панели над окном или в командной строке должна появится надпись «укажите свойство с первым уровнем приоритета в сортировке» - указываем свойство «наименованием изделия или материала». Нажимаем ОК.
6. С верху панели над окном или в командной строке должна появится надпись «укажите свойство со вторым уровнем приоритета в сортировке» - указываем свойство «марка изделия или материала». Нажимаем ОК.
7. С верху панели над окном или в командной строке должна появится надпись «укажите свойство с третьим уровнем приоритета в сортировке» - указываем свойство «… L=». Нажимаем ОК.
8. Наверное, на 5-ти уровнях можно и ограничиться.
9. Если атрибут «категория материала» есть, а в нем нет записи, то при обработке программа останавливается, подсвечивает и зуммирует элемент, выводит его эффективное имя, техническое имя, поле для записи и предлагает заполнить этот атрибут. Если в блоке нет такого атрибута, то все детали маркируются и нумеруются в соответствии с алфавитом. Все что найдено также сортируется по алфавиту, чтобы указав в атрибуте «Категория материала» - значение «Техника\Дорожная\Грузовые автомобили», в других блоках «Техника\Дорожная\Бльдозеры» с начала были собраны все блоки «Техника\Дорожная\Бльдозеры». А затем «Техника\Дорожная\Грузовые автомобили». Это дает возможность разделять категорию на подкатегории не наращивая количество атрибутов. (Разделитель - обсуждается).
10. Создать набор секущей или не секущей рамкой с возможностью многократности.
11. Набор создается с фильтром «только блоки с атрибутами)
12. Выбрасываем из набора все блоки не имеющие указанные атрибуты, причем и те, в которых есть только один из указанных атрибутов. Желательно, чтобы при этом машина выбрасывала сообщение о найденных «бракованных» блоках.
13. Из общего набора создаем наборы, включающие в себя только один вид категории материалов.
14. Берем первое имя – проставляем блокам с этим именем в указанном атрибуте – если Нумерация – номера, а если Позиционирование, то позицию. (при позиционировании заполнение атрибута проводить присоединением значения позиции к существующему тексту в значении атрибута).
15. Сохраняем имя блока, первое и последнее значение номера или номер позиции в переменной blk_num или blk_poz (в зависимости что происходит) и переходим к другому имени блока.

Результатом работы макроса является пронумерованные и позиционированные блоки. В памяти две переменные со списком списков результатов нумерации и позиционирования.

Условия изменены!

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

Добавлено:
Создание основного набора - отдельной функцией сделать надо, чтобы ее можно было потом подменить на более крутую, работающую с внешними ссылками.

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

Ну вот, я проснулся. по поводу ТЗ. Соглашения:
1. В динамических блоках разговор о *Unnn не идет
2. Состояние блока определяется его динамическими свойствами или их набором, как-то Visibility, Look up, Distance и т.д.
3. Во избежание накладок, значимые для спецификации свойства должны иметь уникальные имена
например параметр длинны не Distanse, а Seekdistanse (например)
не Visibility, а TipTrub (или что оно там значит)
4. ТЗ должно выглядеть так
4.1 Из выбранных пользователем объектов, отобрать все динамические блоки с атрибутами
"КАТЕГОРИЯ_МАТЕРИАЛА", "НАИМЕНОВАНИЕ_ИЗДЕЛИЯ" и что там еще нужно
4.2 Сгруппировать все по значению атрибута "КАТЕГОРИЯ_МАТЕРИАЛА"
В пределах значения атрибута материала используется сквозная маркировка позиций (для труб с 1 до N, для ковров с 1 до N) с занесением полученной позиции в артибут POS
В пределах значения "КАТЕГОРИЯ_МАТЕРИАЛА" (например для труб)
сгруппировать по "НАИМЕНОВАНИЕ_ИЗДЕЛИЯ" (Труба ДУ-150 , Труба ДУ-159)
в пределах одного "НАИМЕНОВАНИЕ_ИЗДЕЛИЯ" (Труба ДУ-150) сгруппировать по значению динамического свойства "Тип,марка,позиция" (Ст 159х4,5-1-ППУ-ПЭ, Ст 159х5-1-ППУ-ПЭ) с сортировкой по возрастанию
в пределах полученной группы отсортировать по возрастанию значения динамического параметра SeekDistance с округление до 50 в большую сторону (или до ближайшего 50?).
Обновить динамический параметр SeekDistance полученным значением (подравнять блоки) и занести значение в атрибут Dlina
Посчитать количество блоков с одинаковым параметром SeekDistance
Получаем спецификацию:
Трубы
поз.1 Ст 159х4,5-1-ППУ-ПЭ Труба ДУ-150 L=2500 6 шт.
поз.2 Ст 159х4,5-1-ППУ-ПЭ Труба ДУ-150 L=3000 6 шт.
поз.3 Ст 159х5-1-ППУ-ПЭ Труба ДУ-150 L=2500 6 шт.
поз.4 Ст 159х5-1-ППУ-ПЭ Труба ДУ-150 L=3000 6 шт.
поз.5 Ст 159х4,5-1-ППУ-ПЭ Труба ДУ-159 L=3000 6 шт.
Ковры
поз.1 красный Ковер персидский L=2500 6 шт.
поз.2 красный Ковер персидский L=3000 6 шт.
поз.3 синий Ковер бресткий L=2500 6 шт.

Подготовить контрольный пример (файл) с наличием N кол-ва разных блоков и посчитанной спецификацией

Примерно такое ТЗ я жду. Ты этим живешь, поэтому многие вещи, понятные тебе для меня пустой звук (белые буквы на белом фоне).

Еще пару моментов.

1. Я уже сделал входную часть проги, которая получает из файла *.xls последовательность сортировки и подсчета элементов. Дело в том, что этот файл (*.xls) является документом сопровождающим проект. Если я сделал спецификацию, используя определенный выбор и порядок, то эта настройка должна быть сохранена, что я и сделал.

Я могу вам прислать эту часть, НО! это уже не разрозненные части лиспа и не функции. Это уже надо беречь, до тех пор пока ЭТО не будет окончательно закончено и оформлено. Если вы хотите миру что-то подарить, то вы должны с начала доказать, что ЭТО ваше, и что оно у вас есть. Я намерен передать продукт в офисы крупных компаний бесплатно, но с оформлением определенных условий (выложить на сайт для бесплатного скачивания, не стирать авторство и т.п.). Поскольку ты Kpblc де-факто соавтор, не плохо было бы сделать это де-юре. И к тебе VVA это тоже относится.

Еще раз предлагаю рассмотреть концепцию. Я выкладываю *.xls и "методы расчета".

Давай тогда пока не будет оформлено решение в коде, дальнейшие разговоры вести по email/ICQ.

Открою. Скорее всего, вечером - TDMS, гидрит ее налево, всю малину подпортила. Не вздохнуть. К вечеру, может, подостыну, выскажусь насчет #358.
P.S. Supermax, я в ПМ тебе отписался насчет связи со мной.

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

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

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

Пока дите спит, попробую ответить сразу и на ТЗ, и на все остальное.
> #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 как баран на новые ворота, ничего не понмаю Думаю, что пройдет, и я до всего допетрю

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

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

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

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

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

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

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

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

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

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

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

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

Еще добавлю:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Способов запуска макросов явно не один. Я считаю макросы приложением к 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 загружает функции из этих файлов и пути к ним не сохраняет. А так - дешево и сердито. Инсталятор из одной строчки.

Добавлю:

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

Ххе, и кто ж будет такие строки прописывать, скажи на милость? Пользователь должен запустить инсталлер и больше ни о чем не задумываться. Я такое минут за 20 нарисую в InnoSetup + ACADInst. И нигде не понадобится дополнительно указывать путь до загрузчика.
С позиции "обезьяны с гранатой": машина с новым acad'ом, жмем на интересную кнопень. Опа, запрос на нахождение какого-то файла! Да не буду я искать, нажму Esc. И все, идеология накрылась медным тазом.

Ошибка ИМХО. Особенно для модульных систем. Эта информация не только не нужна, но еще и вредна зачастую.

Могет быть, могет быть.
Ты говоришь Только вот вопросы, как обезъяна попала в кад? Какую кнопень ты имеешь в виду? И чем отличается хождение по папкам в поисках install.exe, от хождения по тем же папкам в поисках чегототам.lsp?

А вообще-то не о том мы спорим. Давай ставить вопросы прямо. Есть такое мнение (у Kpblc-а) что наработанные тексты надо упорядоченно соскладировать по папочкам и все дерево устанавливать инсталлятором с пропиской в реестре Widows.
Аргументы следующие: Создаем зону в виде дерева папок, в которой отвоевываем у остальных прог место только для макросов (наших есс-но). Наши тексты будут ХОТЕТЬ, чтобы такая зона была обязательно и ориентироваться в ней по заранее прописанному в текстах алгоритму. Как только макрос пытаются загрузить самостоятельно (как это пытался сделать я) получают дулю с маком.
С одной стороны порядок (в смысле качества организованности) будет таким, каким мы его создадим, с другой стороны при дальнейшем наращивании текстов не надо будет ломать головы над "всеобщим хаосом" Windows.
Я правильно выразил твое видение?

Есть еще вариант установи, как это делает KITOX
http://www.kitox.com/kitoxtools_ru.php
Цитата

DWG является поставщиком пути. Остальное у Алексея уже есть.

Еще добавлю про Load Application...
Там есть такая галочка "Add to History" и такая закладочка "History List" А в этой закладочке прописываются загруженные лиспы и причем в порядке History. Данные эти не умирают с выключением када, что говорит, о том, что где-то есть файло в которм сие есть (найти бы).
Надо проэксперементировать и ответить на ряд вопросов:
1. Если при загрузке файла в тексте была ошибка и произошел сбой выполнения функции лиспа пропишется ли такой файл в историю?
2. На каком этапе происходит эта запись?
3. Можно ли прочесть эту историю, если последнее "завещание" написанное на лиспе в загружаемом файле это прочесть последнюю запись истории.

На первый вопрос ответ готов - прописывает
Теперь вопрос ГДЕ ЭТА СВОЛОЧЬ?

Во-первых, процитирую:

(с) "САПР на базе AutoCAD - как это делается". Стр.55.
Дальше перепечатывать не буду - некогда.
Во вторых: "какую кнопень"? Да любую! Я говорю про первый запуск системы. Рекомендую скачать VMWare Server или любой другой софт, создающий виртуальный комп, на этом виртуальном поставить винду и acad. И на виртуалке пробовать различные методы и средства. Очень пользительно.
---
Добавлено:
> #339: Эта история хранится в реестре. Подробный рассказ о моих мытарствах с ней есть здесь. Еще раз говорю, что приложения, записанные в Autoload Startup suite, грузятся во все профили AutoCAD'a.

Да я вообще люблю всех (особенно когда жена уезжает на юг отдыхать с дочкой). И теток тоже. Обезъян с гранатой знаю, особенно хорошо их знают сисадмины. Вы сударь предлагаете сделать обезъяноустойчивую прогу? Но за все надо платить. Чем будем расплачиваться за эту устойчивость?
Ладно, это все шутки. Почему реестр, а не autocad2006.cfg?