Supermax, я не хочу тебя расстраивать, но:
DIESEL и Script не всегда хороши. Лично я, работая только в одном документе, где-то за 2-3 месяца (изучая с "нуля") уперся в их ограничения (к примеру, команда может быть длиной только 255 символов, не более, чего зачастую попросту мало. Добавлено: для mns и mnu, в cui вроде как длина не ограничена.). А также некоторые неявные проблемы. Например, на макро-языке (там будет уже не только DIESEL) написать программку вида "запустить рисование полилинии на определенном слое, с определенными настройками системных переменных; в случае завершения, как успешного, так и ошибочного, вернуть обратно настройки AutoCAD'a" мне написать не удалось.
Cui написан не не DIESEL. Он вообще-то написан в текстовом режиме, кодировка UTF-8, формат - XML. MNU, MNS пишутся в обычном текстовом редакторе в кодировке Windows-1251. А вот макросы, которые засобачиваются на кнопки - те да, там DIESEL применяется достаточно широко, особенно в штатных командах. Хотя лично я предпочитаю все же Lisp использовать, где это возможно.
Насчет "расширяет возможности" ты ИМХО погорячился. Но, поскольку я могу и ошибаться, приведи пример. Лично я столкнулся только с одним вариантом - работой с modemacro, значение которой зависит от активной закладки, там проще сделать именно на DIESEL'e, не заморачиваясь с реакторами.

Ну, очень рад, что ты знаком с этими языками. Будет кому мне помогать.
С применением - ты явно перегнул палку. Всему свое место. Даже 255 символов могут очень многое.
Я в частности не сноб AutoLispa. В частности, я разговаривал с одним кадром, так тот даже команды AutoCAD-a не хочет применять в макросах. А я вот применяю. А когда их применяешь, то язык макрокоманд очень сильно изменяет правила пользования этими командами. В cui-файлах есть строки <command> и далее сполошной DIESEL и Lisp. В частности в отношении команды _refedit я нашел запись, в которой явно написано, что если по окончании команды в системной переменной Refeditname (getvar,refeditname) "") то все сбрасывается и отменяется. А у меня соответственно зародилось подозрение, что при чтении ссылки из другой ссылки тут как раз может и не быть ее имени. Если этот пункт .cui-файла как нибудь обойти, или заблокировать, то что-то может измениться.
Краски у художника должны быть разные, тогда и картина получится стоящая. И нельзя одной и той же краской рисовать половину картины - не красиво. Я "квадраты Малевича" создавать не хочу.

Ну или то же самое, но по-русски:

Не думаю, что оно тебе сильно поможет.

Я тоже не хочу. И не применяю. Потому что "маловато будет". К примеру, стандартная команда одной кнопки меню у меня выглядит так:

Работает на ура
Дальше. Я думаю, я уже показал, что до состава внешней ссылки можно добраться и не входя в _.-refedit. Проанализируй код на досуге.
Пользуясь твоей аллегорией, решаемая здесь задача - как гравюра. А ты туда граффити просишь добавить

Kpblc, ссылка вставлена с поворотом и сдвигом в другую ссылку, та с поворотом и сдвигом в третью, и т.д. Чтобы расчитать, какие элементы надо выбрать в этой ссылке, надо все дерево вложенности поднять, все координаты пересчитать и ПСК этой ссылке изменить, чтобы секущая рамка, или ее цифровой эквивалент определили нужные примитивы. Более "Китайского" способа придумать не возможно. ДА! Можно, но только после обследования у врача психиатра.
REFEDITNAME - я изменить (пока) не могу. Да наверное и не понадобится. А вот отловить конец выполнения команды и ее прочесть - попробую. Есть ОЧЕНЬ сильное подозрение, что причина сваливания в *Cancel* кроется именно в том факте, что срабатывает


Все начинается с

Очевидная строка запуска команды.
Все остальные - имет строки автоматического срабатывания

Если нет значения, то запустит _add
Другая - запустит ^C^C_refclose
Все сплошь завязаны на IF и значение refeditname.

Есть правда еще одно подозрение. Когда запускается _-refedit, да и любая другая команда, она начинается с чего? - с ^C^C это сбрасывает выбранный набор. Ручка гаснет. Далее как правило следует в макросе либо _Previous либо _Last из набора Select, а их то и нет! Мы ведь только ручку включали, а набора не было! Вот и выходит, что "". С начала надо как-то вставить в набор Select-a эту ссылку, а потом уж запускать _-refedit. Чтобы запустив _Select "L" или "P" опять включилась ручка. Но как это сделать???
Надо наверное попробовать _Add

К #205
Я не зря тебе указывал на разные владельцы примитивов (свойство Document). Поэтому выполнять подобную математику придется, как ни крутись (это если ты не откажешься все же от идеи получать "неполный" состав внешней ссылки).

Supermax,

Попробуй всетаки зпустить код из сообщения 190
http://forum.abok.ru/index.php?showtopic=1...st&p=139272

На данный момент он просто подсчитывает сколько блоков и сколько ссылок находится в любом файле.
Но в переменной listobj хранятся все графические VLA-объектs исследуемого файла. вот по нимто и можно пересчитать любую информацию, при этом все координаты базовых точек будут в мировой МСК документа из которого данный лисп запускался и будут доступны все имена блоков без искажений. И после подсчета в документе не остается временного мусора.
Это вроде то что тебе нужно только без ковыряния ссылки.
Если такой подход устроит то будем развивать.

Kpblc говорит мне о получении данных не полной ссылки, Mmax - об альтернативном методе получения результата, все это чудесно и интересно НО! Прорабатывая вариант с Refedit я натолкнулся на некоторую загадочную неправильность ее поведения. Выделяемые ручкой объекты я не только в refedit не могу передать. Я их в блок вставить не могу, в группу вставить удалось, но после команды select "G" и далее указание имени группы, куда я вставил отмеченную ручкой ссылку - машина систематически уходт в накаут, то есть фатал еррор. Объект есть объект, если я его нашел, дамп свойсв и методов прочел, то эти свойства и методы должны работать, а на деле происходит совсем иное.
Понимаете, мужики, продвижение к конечному результату - дело великое, но когда сталкиваешся с преградой, до того как принять решение, об изменении маршрута следования, эту преграду надо "понять", обосновать необходимость перестройки концепции, да просто удовлетворить любопытство - что за фигня такая на дороге легла и пройти не дает. На дорогах, где все чисто и просторно, ничего интересного не найдешь. А вот разбирая такие "глюки", не только находишь много нового, а еще и глубже начинаешь понимать систему, что в дальнейшем дает возможность не наступать на эти грабли повторно.
Многие вещи являются недоработкой программистов Autodesk-a. причем очень серьезной не доработкой. Как это так, команда без префикса работает полностью, а с префиксом - частично? Вы понимаете, что за этой информацией стоит? Полазьте на их форумах. Я например много раз видел сообщения, результатом которых был очередной сервиспак. Мне уже фиолетово, refedit это, или какая-то другая команда. Работать в программе, которая имеет известный дефект как-то страшновато.
В общем, последний аккорд:
Что такое на физическом уровне процесс выбора объекта? В описании команды select, включение ручек подается как второстепенный и совсем не обязательный процесс. Главнее его - подсвечивание объекта контурными линиями, да и то не как действие определяющее этот выбор, а скорее как антураж этого выбора и тоже не обязательный процесс. Что же такое сам выбор? Очень хочу это понять.

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

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

Mmax, я спрашиваю про механизм выбора объектов, а не про определение принадлежности объекта к родительскому объекту. Вот ты к примеру, нарисовал линию. Щелкнул по ней мышкой, она запунктирилась и у нее включились ручки. Если отбросить антураж выбора, то есть включенные ручки и пунктирное выделение, что еще происходит в программе, что определяет этот выбор. Ты же понимаешь, что сбросив системные переменные, отвечающие за подсветку и индикацию ручек в 0 ты выбор этим не отменишь? Вот я и мучаюсь этим вопросом. НО! я готовлю серьезное послание на сайт Autodesk-a с утверждением в не корректности работы команды, сам понимаешь какой. Там на вопросы отвечают разработчики када и им должно быть не безразлично, когда название темы к примеру "_-refedit не работает!" только по английски. Они мне еще ни разу не ответили и такое впечатление, что я затронул какие-то скрытые мотивы, не дающие им возможности адекватно реагировать на поставленные вопросы.
Как только я с ними разберусь и пойму, что дальнейшая борьба результата не принесет, то тут же начну разрабатывать твой вариант вставки и сборки модели.
Твой код я внимательно изучил и полностью согласен с основными критериями подготовки процесса, а вот реализация вставки должна быть с переназначением имен слоев, чтобы все вставленные элементы были идентифицированы к конкретному файлу.
Изменение конструкции вставленного должно быть тоже отнесено к определенному файлу ссылки-прототипа, чтобы можно было редактировать файл-матку и даже, при разных вариантах одного и того же вставленного фрагмента, создавать файлы-репликанты, с копиями фрагментов.
Kpblc, твой вариант с пересчетом тоже должен существовать, но скажи, как приравнять координаты вставки элементов к единому пространству? Вариант mmax-a дает прямую возможность частичного выбора объектов, а как в твоем случаеэто реализовать - не понимаю. Отказаться от выбора рамкой не трудно, но тогда надо локализировать не только этажи, но и все помещения в них. Как заранее узнать, что потребуется? Появление правил разрушает лояльность пользователей к программному продукту.
Ссылки, ссылки, сылки! Что с ними делать? Никто не поймет, если взять и сказать, типа вставляйте, но идентификация объектов должна быть развитой и не зависимой, и корректирование - только через файл-матку в слепую.

> Supermax, #209:
Это не я говорю о получении неполного состава внешней ссылки, а ты По крайней мере у меня сложилось такое мнение по результатам темы. Потому что пройтись по всему составу внешней ссылки активного документа лично у меня проблем не вызывало - проанализируй мой код.
> Supermax, #211:
Вот уж не думал, что надо будет рассказывать элементарные вещи...
Есть несколько вариантов получения указателей на элемент:
- (entsel [msg]) - получает ename-указатель на примитив, на котором "щелкнул" пользователь + координаты точки, в которой был выполнен "щелчок" в текущей системе координат. Выбранный примитив временно подсвечивается пунктиром. Результат (если отбросить ненужное) - ename
- (nentsel) - аналогично, но при "щелчке" на примитиве, входящем в блок или внешнюю ссылку, указывает данные "по хозяину". Никогда не пользовался, поскольку практически не требовалась. Результат - ename
- (ssget) с различными фильтрами - получение набора примитивов. Результат - pickset (!) Рассматривается ниже
- (vlax-for) - немного отдельная песня. Сейчас ее рассмотрим поближе.
Извращения типа того, чем так любит страдать Лентяй на dwg.ru, я не рассматриваю.
Итак, погнали разбор наборов?
(ssget) - позволяет получить набор примитивов. Сконвертировав его в список примитивов, мы можем делать с ними все что угодно. Примерно так:
Сейчас мне будет задан вопрос: так все равно же выполняется выбор, и примитивы подсвечиваются!
На что я отвечу: при формировании набора типа (ssget "_X") "подсветка" примитивов не выполняется! А доступ к ним все равно есть.
Теперь насчет (vlax-for)
(vlax-for) позволяет пройтись по всей коллекции, например, описаний блоков, и для каждого элемента описания получить его состав. В этой коллекции обязательно присутствуют блоки с именами *Model_space* и *Paper_space*, обозначающие соответственно пространство модели и пространство листа. Так, для файла с 2 пространствами листа (абсолютно пустого) функция видавернет
Соответственно, проходя по составу уже этих блоков, можно получить их состав (в пустом файле нарисуем линию "от балды" в пространстве модели и еще одну в пространстве листа, запускаеми получаем нечто типа:
Хотя бы один объект подсвечен? Не-а. А доступ получен? Ага.
Так что подсвечивание объекта не является критичным для получения доступа к нему.

для справки: в vla-представлениях примитивов все координаты хранятся в мировой системе координат. Соответственно выполняется нечто типа:

И всех делов. На выходе ты получишь реальные координаты начала отрезка при условии, что xref имеет 0 угол поворота. Для "ненулевого угла" и "немировой системы коодинат" думай уж сам Вот такая я сволочь.

Развернутое диалоговое окно, плюс дополнительная фильтрация. Ты думаешь, я от безделья только полгода назад начал заниматься спецификациями вплотную? Не-а, я почву готовил.

Программно? Только читать. Любые изменения должен вносить пользователь. Сугубо ИМХО.
[offtop]Странное дело - мне приходят уведомления о новых ответах, только если отвечал не Supermax и не я. Учитывая интенсивность общения, по меньшей мере хочется исправить. Как - пока не знаю. Блин.[/offtop]
---
Добавлено: И тишина. И только количество просмотров растет...

Ох уж эта Анапа! Связь - полный кишечник при сильном расстройстве. Пока загараю. Процесс вставки элементов из другого файла должен начинаться с копирования файла-матки в промежуточный файл, далее переименование всех слоев в слои с именами состоящими из имени файла-матки - разделитель - прежнее имя слоя. Далее объединение всех элементов в блок с именем файла-матки. Далее - надо где-то хранить параметры вставки такого блока (X, Y, Z, масштаб, угол поворота и т.п.).

Выдумываешь механизм внешних ссылок?

Да вот refedit с префиксом глючит. Получается, что только в ручную можно работать. Поещуку передам материал, пусть убедится и подтвердит сей прискорбный факт, а затем уж в AutoDesk настучу.
Право на жизнь имеет любая форма существования. Почему бы и такой вот способ не потрогать руками? Существующие внешние ссылки это не отменит все равно. Но в некоторых случаях может что-нибудь интересное родится.

Ты только Николаю Николаевичу и ссылку на эту тему передавай уж заодно Может, рассудит наконец нас с тобою

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

Сижу в Интернет клубе, в окружении геймеров-маньяков. Орущих, и очень шумящих. Связь через телефон только на прием. Очень много мыслей по поводу удаленной работы.
Раньше 30-го работать по настоящему наверное не получится.

Кстати, есть предложение. Раз уж ты хочешь иметь в элементах чертежа только ссылки на базу, то тебе и карты в руки. Где и в каком виде надо разместить эту бирку, чтобы машина ее обнаружив, передала (опять вопрос - что? и куда?). Бирка может быть и атрибутом и расширенными данными и пр.
Это я к тому, что можно сделать "И".
Есть также вопрос: Собираешся ли ты работать с виртуальными элементами? Ну это когда коммуникации представлены линиями, покраска плоскостями, объемы 3D солидами. Если да, то куда лепить бирку?

Могу только посочувствовать. Сижу дома, сильно хочется спать, сегодня был на даче, ноготь срезал до мяса (больно, блин), так что за ошибки (грамматические) прошу не бить особо сильно.
Мыслей не меньше, а вот времени...

Отвечу сразу на все. Во-первых, машина "сама по себе" эту (как ты ее называешь) "бирку" сможет обнаружить только когда ее об этом (явно или не очень) попросит пользователь. И обрабатывать она ее будет так, как ты скажешь.
Я против расширенных данных и против атрибутов. Против РД потому, что, во-первых, их структура слишком жестко задана; во-вторых, серьезные ограничения по объему (16 кб); в-третьих, эти РД распеределяются между всеми приложениями. Для справки: попробуй засунуть свои РД в примитив видового экрана листа. Не получится - онм уже забиты приложением ACAD.
Я против использования атрибутов во-первых, потому, что пользователь может поменять эти данные, используя штатные средства AutoCAD'a. Соответственно прога попытается обработать эти неверные данные, и в лучшем случае выдаст nil или ошибку. В худшем - она их обработает, выдав некорректный результат. Во-вторых, потому, что атрибуты применимы только для блоков. А этого иногда может оказаться недостаточно.
Как пример (черт с ним, разберем блок вкупе с БД):
В БД есть таблица, например, решеток вентиляционных примерно такого вида:

В блоке болтается всего 2 атрибута - первый (DB_TableName) - это имя таблицы; 2й (DB_TableID) - ID записи. Разработана функция получения значения атрибутов с блока примерно такого названия: (GetBlockAttrValues BlockReference AttributeName). Также разработана функция выполнения запроса к БД, например, (GetDataBaseSQL SQLQuery).
Получаем указатель на блок:
Контроль значений пока оставим в стороне, оно не критично.
Формируем запрос:

Пишу без запущенного када, так что со скобками могут быть проблемы.
Теперь указываем блок, в котором DB_TableName=tableVentNets и DB_TableID=1. Выполняем запрос (GetDataBaseSQL sql), получаем Cost = $10.00
А вот теперь представь себе ситуацию, что пользователь взял да и поменял 1 на 2 в DB_TableID - просто "посмотреть, а чего будет?". Выполнение того же самого sql, вернет уже не $10.00, а $200.00!
И это только одна таблица, только один параметр. А, как ты сам понимаешь, их может быть ооочень много.
Ты же не сможешь отследить такое изменение атрибута! Вешать объектный реактор на блок на изменение одного из его подпримитивов? Запаришься, и все равно я смогу это обойти. Я просто запущу акад без твоих дополнений и все, пишите письма мелким почерком.
Поэтому данные должны храниться в месте, недоступном для простого пользователя, и не иметь таких явных ограничений, как РД. Выход - ldata, функции я показывал.
ldata, кстати, можно присоединить вообще к чему угодно, им по фигу, с чем работать.
Как пример, опять же (реализованный): в элементы (блоки, полилинии, отрезки...), вставленные с использованием интерфейса к БД, вставляются ldata вида '(("table" . <ИмяТаблицы>) ("id" . <НомерЗаписиВ_Таблице>)) и этого достаточно, чтобы получить при составлении спецификации и полное наименование, и стоимость, и любые технические (и не только) параметры именно этого примитива. А уж свести все в единый список - ну тут вообще неинтересно обсуждать, это самая скучная часть задачи.

Приехал из Анапы и сразу заболел. Горло, сопли и никакая медицина не берет. Уже на антибиотики перешел. Сегодня даже коньюктивит начался. Глаз ночью слезился, слезился, а потом взял и склеился.
Николай Николаевич подтвердил факт не корректной работы команды refedit. Посоветовал связаться напрямую с обслуживающим персоналом службы поддержки.
Я и по поводу наших разногласий мнение спрашивал. Он сказал, что это дело вкуса. Что при крупных объемах лучше СУБД, а при мелких - хранить даные в примитивах. Логически так оно и получается, данные о товаре делают примитив более громоздким и если таких примитивов много, то в целом модель становится неповоротливой. Николай Николаевич еще высказал мнение, что надо копировать из базы данные в примитив и наоборот, чтобы избежать искажений и обеспечить пополнение базы. Сделать перекресное наполнение в принципе можно, только я боюсь, что в случае развития торговли материалами и оборудованием с сопровождением виртуальными аналогами будет очень не просто сделать адаптер параметров для перекачки из этих изделий в базу их данных.
Есть еще один аспект в наличии атрибутов в блоках. Атрибуты эти могут быть вынесены в другой слой, а сам слой - выключен. Кто и в каком слое будет их устанавливать и какие слои будут перекачевывать в модель с вставкой блока из базы донара - вопрос не простой. Скорее всего ожидается "замусоривание" таблицы слоев.
Сейчас я пытаюсь разработать методику замера времени обработки массива блоков с атрибутами и без. В частности поворот орбитом.
Пока замораживаю работу над выбором секущей или не секущей рамкой с включением внешних ссылок. До полного прояснения с refedit. Вообще ушел от работы с внешними ссылками. Создавать аналог внешних ссылок, так как предлагает mmax очень трудоемкий процесс. Скорее всего я потихоньку его буду прорабатывать, но все силы на него тратить сейчас не могу.

На самом деле (ИМХО) достаточно прописать только реактор на закрытие документа - хоть командный, хоть базы документа. И в этом реакторе создавать объект коннекта к БД, проходить по всем примитивам dwg-файла (возможно, с обработкой внешних ссылок) и формировать несколько SQL-запросов, которые пакетно и выполнять. Об ошибках сообщать.
Ставить такое на реактор сохранения файла (или не дай боже на добавление примитива в файл) не советую - кад слетит, и база может следом отправиться.

Наконец-то я придумал как выкрутится из этой ситуации и даже кое что попробовал.
Алгоритм дальнейших действий таков:
1. После того, как пользователь установил в видовом экране положение модели, ну скажем, 3D-орбитом, он запускает макрос и после процедур определения параметров фильтра выбора наконец-то добирается до секущей рамки. Которой он несколько раз (ну как правило, оного раза не хватает) обозначает пространство учета.
2. Макрос, запомнив координаты всех этих действий с рамками делает следующее:
- Сохраняет в переменной текущее имя файла
- Сохраняет (или не сохраняет, пока не решил) текущий файл.
- Сахраняет КАК все тот же файл, но под другим, технологическим именем. При этом, в окне автоматически сменяется файл-оригинал на сохраненный файл. (проверено, макрос продолжает нормально работать)
- Находит все "верхние" внешние ссылки и в переменных записывает их имена и имена вложенных в них внешних ссылок
- Запускает -XREF и далее B, перечень имен "верхних" ссылок, что приводит к преобразованию всех ссылок в блоки. (проверено, внутринние ссылки автоматически преобразуются во вставленные блоки с именами как у ссылок)
- Поочередно выделяет блоки с именами как у внешних ссылок из которых они образовались и их EXPLODE.
3. Далее, извлекая данные рамок опять проводится формирование набора, который на этот раз состоит из одних элементов не являющихся внешними ссылками.
4. Делается подсчет
5. Открывается старый но образцовый файл
6. Убивается файл, в котором только что были разчленены внешние ссылки.

Вот так я избавился вообще от REFEDIT.

Мне интересно, как получить координаты контрольных точек наборов? И потом, переход лиспа из текущего документа в другой моментом убивает все его результаты выполнения. Значит, их придется куда-то сохранять (например, в txt-файл). Но вот вопрос - а что там сохранять-то надо будет? Все подряд?

Ну во первых, наборы в файле-оригинале мы не создаем. Мы только рамочкой машем и ее координаты записываем. Как я уже тебе показывал.
Во вторых, как не странно это выглядит, но при работе с командой saveas лисп начав работу в одном файле, продолжает работу в другом, сохраняя при этом и положение пространства модели по отношению к видовому экрану и все значения переменных записанных через setq. А вот после разбиения внешних ссылок мы там наборы и создаем, обрабатываем и сваливаем, уничтожая за собой мосты.
Я пока не пробовал, но открытие нового файла наверное тоже будет делать тоже самое.
Скорее всего, все дело в том, что saveas не переписывает базу рисунка, а просто меняет в ней клеточку с именем файла, вот и получается, что мы никуда и не сваливали, а сидим в той же базе, только нас переименовали.

Э-хе-хе, что-то я заскучал, однако. Расскажу публике о бытии 3D проектирования.
Сижу и проектирую теплотрассу. Оказывается, спрос на ее моделирование очень высок. Если просто линии нарисовать и в спецификации указать общее количество труб, то в процессе ее строительства из-за того, что нет листа раскроя труб, очень много получается обрезков. Прорабу самому приходится карандашиком проставлять размеры на плане и делать монтажную схему. Крутится план, не смотря на его колоссальные размеры и наличие атрибутов во всех блоках довольно терпимо, но на пределе. Благодаря тому, что прокладка теплотрассы выполнена не линиями, а в 3D, очень чувствуются реальные масштабы объектов, хотя они – просто контуры. Это впечатляет заказчика больше чем все остальное.
Второй заказ – смоделировать кирпичную кладку и конструкцию кровли коттеджа. Кладка не из простого кирпича, а из камней Knauf – большие такие кирпичи, однако. С наружи облицован дом лицевым кирпичом.
Уже на середине окон первого этажа (моделирование начато с плиты перекрытия 0,00) подкачка 2,2 гига. Скидываю ряды в специально созданные для этого слоя, которые держу выключенными, все равно крутить объект просто невероятно сложно. Чуть сильнее крутани, или чего-нибудь лишнее в это время нажми – и все, Але-с капут. Явно назрел кризис насыщенности модели элементами (больше 24000). Там к каждому кирпичу еще и раствор пластинками приделан. А если целый микрорайон надо смоделировать? Даже один большой объект и то проблема. Главное препятствие – это догма, что должен существовать такой файл, в котором представлена вся модель. Включить одновременно все внешние ссылки это означает загрузить в память все их элементы, а на какой черт это надо? Ведь в каждом конкретном случае надо только иметь возможность детализировать какой-то фрагмент. Как Google Earth делает? Дает общую картинку, с очень низким разрешением и по мере приближения к точке фокуса удаляет из памяти лишние растры и закачивает новые, более детализованные. В AutoCAD-e же не смотря на то, что вы придвинули к себе модель на столько, что у вас болт на весь экран, в памяти все равно сидит весь теплопункт.
Как сделать так, чтобы модель микрорайона, по мере приближения к конкретному дому, а затем к конкретному теплопункту в этом доме, добавляла к себе необходимые элементы или внешние ссылки и при этом закрывала не нужные?
Думаю, что надо сделать маркеры, при активации которых срабатывает реактор и появляется диалоговое окно с предложением подгрузки элементов (можно целое дерево). Если погасить маркер – все элементы выгружаются, а ссылки отключаются. Можно к маркерам включение-выключение слоев прилепить. Можно сделать активацию маркера так: Подсветил маркер – выскочило окно «вкл / выкл» Нажал «вкл» - маркер стал зеленый и выскочило окно с выбором того, что ты хочешь включить. После выбора маркер потух, а если его опять подсветить – опять выскочит окно «вкл/выкл» и тут можно все выключить.
Таким образом, в разных частях модели, на разных уровнях будут лежать маленькие примитивы (можно треугольники, можно квадратики) при выделении и включении которых модель будет «усложняться», а при выключении «упрощаться».
Включение маркера может привести к появлению кроме дополнительных элементов еще и других маркеров, что позволит углубиться еще больше.
Я чувствую, если покопать в этом направлении, то идеология моделирования очень сильно измениться, а значит, изменится и идеология подсчета материалов и оборудования.
Господа! А ну, напрягли извилины! У кого что на этот счет есть?

А, может, проще все же рендер делать в VIZ'e или 3DSMax? Текстуру натягивать и вперед.
Сугубо ИМХО, поскольку рендером не занимаюсь совсем.

Так не ради визуализации все это делается. Визуализация уже сделана давно, предавно. Нужен ответ на вопрос - сколько надо кирпичей и каких.

Ну тогда хоть через РД, хоть через словари, хоть через ldata записывай материал компонента стены, а потом считывай его. Или переходи на Revit / AA2008 / MEP2008, чтобы не изобретать велосипед В тех пакетах понятие многокомпонентных стен уже давно сделано. Насчет труб и Ко не знаю

Дело даже не в этих конкретных камнях (так они правильно называются). Нет таких в базе программ использующих расчет по условному поганожу. И укладываются они без поперечных швов, что оказывает влияние на расчет массы раствора. Дело в том, что уж сильно быстро наступает в AutoCAD-e порог ограничения по количеству (где-то около 5000 элементов), что естественно беспокоит, так как планы мои - Наполеоновские. Я хочу понять, как надо строить модель, чтобы строить ее до бесконечности, но машину при этом не убить?
Вот у меня на экране 16890 элементов, а скопировать в буфер могу только 5000 (примерно). И это только маленькая часть модели. Мне ее еще строить надо. У меня камень 3,3 гига и 3 гига оперативки. Видеокарта хоть и не за 1000$, но не самая плохая. И такое положение у всех проектировщиков, их заказчиков и разных других службах.
.
Как строить модель до бесконечности?
.
Ясен пень, надо что-то делать с подгрузкой и выгрузкой элементов. Нужно выработать стратегию.

Когда я делал зимние сады, я для 3Д специально делал профили с минимумом скруглений и фасок. То есть сознательно шел на визуальное упрощение модели.
Зачем работать с буфером - не очень понимаю, если честно.
P.S. Специально сделал файл с полумиллионом примитивов - работает, скотина! Хреново, но работает! Intel 2x1.7GHz, 1Gb RAM, Video on-board. ADT 2006 Rus + SP1, ADT 2007 Rus + SP1, AA 2008 Eng

Да, ты прав, чем больше точек в примитиве, тем меньше таких примитивов AutoCAD может проглатить. Хоть он при вращении объекта сам упрощает примитивы, помогает это ненадолго. Аппаратные ресурсы дело конечно не плохое, но лучше придумать какую-нибудь хитрость.

В dwg.ru я не тусуюсь, я там живу Модером я там числюсь со всеми вытекающими
Встречи достаточно регулярно проводятся и в Москве, и в Питере. Надо просто темы смотреть - за московскими встречами я не слежу (все же Питер мне ближе ).

Блин, что значит с 17:00 Мск до 24:00 Мск быть лишенным сети
http://dwg.ru/search.php?zone=2&mod=1&...%EE%F1%EA%E2%E0
показывает, что кое-что все же висит.

http://www.progz.ru/forum/index.php?showtopic=31957#
Испытай свой автокад.
У меня получилось 1 048 576 примитивов LINE, это конечно не 3д. Подсчитал я их командой _LIST, предварительно выделив все.
комп тормозил, но работал.

> mmax : Можно и так посчитать количество (без выделения):

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

Это понадобится делать реактор на изменение выделение (pickfirst-чего-то-там). Занятие малоприятное, доложу я вам. Вдобавок чреватое глюками на вертикальных приложениях.

Есть еще другая, очень похожая идея:
Создаем два одноименных (почти) слоя. Один всегда выключен, другой - всегда включен. Задаем сектор охвата видимости модели. Поясняю: Ставим точку и по отношению к ней определяем размер куба, где эта точка лежит ровно в центре. Куба естественно нет, это только координаты X, Y, Z. Задавая место положения точки обзора (так ее назовем), макрос выбирает в выключенном слое все элементы попадающие в этот куб и переносит их во включенный слой, а все элементы, вышедшие за границы куба во включенном слое - выкидывает в выключенный слой. Поменять принадлежность элемента слою - дело плевое и для обработки быстрое. Теоретически так можно перемещая точку обзора по пространству модели высвечивать только те ее элементы, которые требуются для работы с ними. Таких зон может быть несколько. Можно вместо перебрасывания по слоям использовать включение или выключение видимости объекта (правда я не пробовал это делать и не знаю, как обрабатывается модель с включенными слоями, но с выключенной видимостью объектов в ней). Если слои выключать, то тут гарантировано ускорение работы (проверено многократно), а вот с видимостью не знаю.
Ясен пень, что все слои тогда в модели должны иметь пару, так сказать сиамские близнецы. А то у меня кирпичи все в одном слое и делать каждому кирпичу отдельный слой - .... А так, как фонариком шаришь по модели, а она тебе достраивает ее и скрывает лишнее.
По идее макрос должен получиться не большой.

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

> #239 : посмотри вариант моего аналога Isolate Objects из ADT: http://www.autocad.ru/cgi-bin/f1/board.cgi?t=22342xe
> #240 : под глюками я имею в виду совершенно иное. Например, я сделал свой реактор на двойной клик. Для его корректной работы приходится, во-первых, выгружать один из стандартных arx, а, во-вторых, постоянно отслеживать совместимость с приложениями типа СПДС GraphiCS. И после того, как все сделано на "чистом" acad'e, каково получить систематический вылет ADT или AutoCAD LT именно потому, что выгружен arx? Я такого добра нахлебался полной ложкой.

Я тебе сочувствую. Чес. слово. Писать проги для широкой аудитории это конечно патриотично, но не экономично.
Я очень не приветствую потугов Autodesk-a разнообразить линейку кадов. Гораздо лучше бы было добавлять основному ядру руки и ноги. Так по крайней мере и уровень продвинутости AutoCAD-a вырос бы и пользователи друг друга бы лучше понимали. А так, у них там все лучшие умы разбрелись по версиям када и в результате явная накладка исполнений. Я вот давно понял, что если я не сосредоточу все свое внимание на каком-то одном продукте, то и результат будет - ни рыба, ни мясо. Все эти специализированные исполнения типа десктопов и усеченнных вариантов чес. слово баловство. У нас работает человек пять продвинутых автокадчиков, все они прошли через эти специализированные кады и выбросили их на помойку. У всех чистый AutoCAD. И ни кто их не убеждал. Сами приняли решение.
Есть такой "пивной синдром". Раньше было пара-тройка сортов, люди в них разбирались, ценили. А сейчас, заходишь в магазин - уйма, до неба! И все по большей части - полный отстой. Никого уже не тянет в этом разбираться и слыть ценителем. В результате - те, кто покупал пиво чтобы получить удовольствие от вкуса - вымерли. Остались только те, которые получают удовольствие от количества.
Так и в программах. Когда в проге появляется слишком много кнопок, которые можно применять, но очень редко - их удаляют из панелей и про них забывают. А работа основных команд, таких как например черчение линий - стоит на месте. Эти функции не совершенствуются (что соответствует улучшению вкуса пива), а остаются на старом уровне. Зато появляется много новых функций, что улучшает общее раскручивание продукта. Что творится при этом в теле программы догадаться не трудно. От чего и все твои проблемы с совместимостью.
Могу посоветовать (извини за нескромность). Сам выбери себе лидера среди всех виденных тобой программ и пиши только для него. Пошли все эти другие проги (даже если там есть что-то интересное) куда подальше!
Если не работает макрос под LT - не трудись его дорабатывать. Уважай свой труд. В жизни надо занимать твердую позицию. Сам мне говорил, что всем не угодишь. Если заказчик хочет под LT - пиши для LT. Хочет под чистый кад - это уже другой макрос и за другие деньги. А то слишком кучеряво выходит "чтобы везде работало".

Как сказали на семинаре в Русской Промышленной Компании, самый лучший Автокад - это... 2004-й.

> OVKT : Полные данные на того, кто это сказал, пожалуйста. А так... "Бездоказательно, дорогой профессор. Бездоказательно".
Не верю я в это, не верю. 2004 - не самый плохой кад, но и не самый лучший. Я точно так же могу заявить, что 2006 самый крутой, или 2007. Или 2008.
> Supermax : Ну есть такая фраза: "Что бы мы ни делали, а мухи летом все равно будут". Лидера-то я давно выбрал, но 22 места AutoCAD LT тоже покоя не дают. Под LT я пишу не макросы, а лиспы, вполне нормально работающие (как правило). Есть, конечно, тонкости, но их достаточно мало.
То, что у тебя продвинутые выкинули вертикальные решения, показывают то, что отсутствовало какое бы то ни было сопровождение и наладка. Вопрос к продавцам софта. Читая, что Виталий Филин на autocad.ru делает в MEP, я тихо фигею - какие в нем (в софте, ессно) возможности скрыты.

О! Возможности везде есть. Люди ведь не только за бабки пашут. Интерес и личные идеи реализовывают. Но есть такая пакость как эволюция. Проги, которые имеют то, что имеют благодаря их собственной эволюции так просто с наскока не напишешь. Опыт есть опыт. AutoCAD - эволюционный продукт. Когда начинают что-то с нуля, или на базе известной платформы, то с нуля, сами понимаете, а на базе платформы про саму платформу забывают. Она перестает эволюционировать и все в целом храмает на обе (или сколько там их у нее) ноги. Проанализируйте все продукты "на платформах" и увидите то, о чем мы тут печемся.
Это совсем не означает, что надо все продукты отвергать, просто не надо писать для всей линейки. Кесарю - кесарево, а слесарю - слесарево. Вот драйвера к плотерам ведь все разные. Для каждой операционки отдельно выпущены, а не адаптированы.

Спешу еще добавить, а то сейчас охранники заявятся и будут плакаться, что надо под охрану офис ставить.
Отсутствует общая идеология перспектив развития проектирования. Почти во всех институтах пытаются создать хоть какое-то подобие концепции этой самой перспективы, но разработчики всяких кадов эти концепции не видят, поскольку их к их созданию не привлекают. В результате реализовывать эти концепции нечем. Не видно в AutoCAD-e следов хоть как-то организованных идеалогий. Есть некоторые детали, да только в общую картину никак не склеиваются. Как скажите развивать програмный продукт, если проектирование не развивается?
Была с самого начала установка - с начала моделировать тело, а потом его в Layout-ах в разных ракурсах и разрезах показывать, так кроме железячников этим никто руководствоваться не спешит. Вот какого хрена сделали в AutoCAD-e возможность распечатывать Model? Как людей отучить теперь рамки со штампами в ней рисовать?
Предлагаю сделать диверсию - написать постоянно действующий макрос, который не дает печатать из модели.
Как только станет ясно как будет развиваться проектирование, сразу станет ясно что и как нам писать.

Ну, по-моему, тут звучит "взгляд не с того конца истории". Пространство листа в AutoCAD'е же не сразу появилось. В 12-й версии под DOS его еще не было.

Почему? Архитекторы, работающие в ADT, очень широко этим пользуются.

Не дали, а оставили. Посмотрим, что будет в 2009

Я - пас. Из принципа.

Пардон за маааленький офф-топ. Если осуществить предлагаемую Вами диверсию, то 90% проектных контор на территории нашей необъятной Родины обанкротятся, по причине того, что не смогут распечатать свою продукцию. У Вас здесь интересный, конструктивный диалог о высоких материях, но в реальности львиная доля чертежей выполняется в модели вместе с "рамочками" и печатается оттуда же на струйных принтерах с использованием цветозависимого стиля печати по фамилии "monochrome". Это - будни проектировщиков "на местах" ("местами" эта реальность до сих пор не вышла за границы 14-й версии АвтоКАДа) и с ней (реальностью) тоже нужно считаться:-) Не смотря на все рассуждения, нужно более реально смотреть на вещи.

> Bers : К сожалению (или счастью, не знаю), но минимальная версия AutoCAD'a была ограничена практически в самом начале темы - AutoCAD 2006. В R14 не было объектной модели и VBA, насколько я слышал; также там не было до конца реализовано пространство модели, про дин.блоки и палитры инструментов там даже заикаться не след - засмеют; arx еще не был привязан к студии от MS ну и так далее.
Кстати, эту "диверсию" выполнить лично мне (на моем сегодняшнем уровне знаний) невозможно априори. И кроме того, даже если она будет выполнена, я за полчаса (снести кад - очистить винт и реестр - поставить кад) эту диверсию ликвидну так, что и памяти о ней не останется.

Добавлю немного интересного.
Сейчас собираю дом из отдельных кирпичей, камней Knauf и пластинок-солидов иммитирующих раствор.
Все кирпичи, 2/3, половинки, четвертушки и все виды камней - блоки. Лежат в 0-ом слое. солиды раствора лежат в слое "Раствор кладочный".
С начала (после первых 5-ти рядов) модель стала очень тяжелой. Объединил ряды в блоки и модель стала легче, но по окончании 1-го этажа все равно стала грузить мою нервную систему.
Demontage написал макрос всего из трех кнопок "Включить все", "Оставить выделенное" и "Выключить выделенное". Все, что захочешь можно выключить не зависимо, в каком слое оно лежит.
Дело стало просто кайф!
Сохраняется модель с установками на выкл. и загружается тоже с выключенными элементами. Просто мгновенно!
Когда включаешь все, долго рисует, но рисует исправно, без выбросов "фатала егора". Только начинаешь крутить, или работать с полностью включенными элементами - все! Рушится!.
Хочу макрос переделать на включение и выключение по областям. Точка и радиус области, только не шар, а куб. Все, что в область попадает может быть выключено, или включено, а также вокруг области тоже самое.
Чтобы областей было несколько, вообще, чтобы создавались по желанию сколько хочешь.
А вот подсчет элементов можно делать и не включая их. От дома или этажа один только контур, а установив в нем область подсчитает все, что в ней. Зачем спрашивается их включать?.

Файл огромный, элементов в нем уйма, а работать с ним можно на любой, даже самой "недоукомплектованной" машине. Только меньше элементов надо включать. Я думаю, что даже подгрузку элементов при "включить все" надо делать лотами с диалогом типа "еще грузить?".
Вот делаешь теплопункт и возишся с обвязкой теплообменника, зачем тебе все остальное в памяти, да и обзор закрывает. Чудесный одним словом макрос получился.

Ххе, еще раз смотрим на пост #241. Кстати, интересно было бы посмотреть на этот макрос - насколько оно совпадает с моим кодом .