|
||
| Правила | Регистрация | Пользователи | Сообщения за день | | Поиск | | Справка по форуму | Файлообменник | |
|
Поиск в этой теме |
21.07.2005, 12:25 | #1 | |
Вопрос про внесение расширенных данных в примитив.
Регистрация: 21.07.2005
Сообщений: 7
|
||
Просмотров: 8693
|
|
||||
Project Engineer Регистрация: 05.01.2005
Лос Анджелес
Сообщений: 1,392
|
В чем проблема-то? В спецификацию переносятся объекты типа "строка", т.е. код 1000. ActiveX-ом вытаскиваешь соот-е свойство, преобразуешь его, если надо, в текст и загоняещь в Xdata с кодом 1000. Ниже - пример программы формирования выносок трубопроводов. Обрати внимание на использование слоя для описания назначения трубопровода.
Цитата:
|
|||
|
||||
Project Engineer Регистрация: 05.01.2005
Лос Анджелес
Сообщений: 1,392
|
В чем проблема-то? В спецификацию переносятся объекты типа "строка", т.е. код 1000. ActiveX-ом вытаскиваешь соот-е свойство, преобразуешь его, если надо, в текст и загоняещь в Xdata с кодом 1000. Ниже - пример программы формирования выносок трубопроводов. Обрати внимание на использование слоя для описания назначения трубопровода.
Код:
|
|||
|
||||
Регистрация: 21.07.2005
Сообщений: 7
|
Про спецификацию понятно... там можно обойтись только текстом. (это я уже почти сделал)
Задача несколько шире - хочу чтоб примитив был не просто примитивом, а именно элементом со своими параметрами. Т. е. например есть примитив "блок". Например это спринклер. В расширенные данные хотелось бы внести 1. - название (для спецификации) тип "строка" 2. - производитель (для спецификации) тип "строка" 3. - расход воды (для рассчета) - тип "число" 4. - вариант установки, розеткой вверх/вниз (для рассчета и автоматической отрисовки аксонометрии) - тип "логический" 5. - ссылка на блок_условное_изображение_на_схеме (для автоматической отрисовки аксонометрии) - тип "строка" У меня уже есть наработки по автоматическим рассчетам, по автоматической отрисовке схем и аксонометрий из планов, но чтоб объединить все в единую систему надо все данные для авторассчетов и автоотрисовок внести в примитив. Как все это в него запихнуть? Единственное что мне пришло на ум - все данные преобразовывать в строку вида "| 1.ХХХ | 2.XXX | 3.XXX | 4.XXX| 5.XXX |", засовывать эту строку в 1000 тип, а потом при каждой надобности её "раскодировать". Но мне кажется что такая система будет работать очень медленно. Есть свежие идеи на эту тему? |
|||
|
||||
инженер Регистрация: 13.12.2004
Минск
Сообщений: 496
|
>>X28
Может Вам лучше работать с присоединенными данными, как со словарями? Формируете список данных в виде списка ((1 25) (2 труба) (3 200) (4 25) и т.д) или ((номер 1) (тип труба) (диаметр 200) (расход 25)), Вам выбирать, но суть первой позиции в списках возможность поиска нужного значения по метке, затем присоединяете их к примитиву при помощи vlax-idata-put (нужна утилита на Лисп для удобства работы) с кодом словаря (Задается пользователем для последующего извлечения необходимых данны из словаря). В последующем эти данные можно извлекать из объекта при помощи vlax-idata-get и нахождить в списке необходимых данных (опять же нужна соответствкующая утилита на Лисп) остальна работа уже по потребностям! Причем эти данные могут быть как строковые так и числовые, для списка разницы нет, тем более их всегда можно конвертировать. |
|||
|
||||
Можно не формировать составную строку с идентификатором типа данных, а предварять ее этим идентификатором записанным в группу 1070 - (1070 . 1)(1000 . "Name")(1070 . 2)(1000 . "Description") и т.д.
Соответственно задача формирования|разбора данных упрощается. Еще можно группировать данные, т.е. вводить аналог списка по группе (1002 . "{") ...... (1002 . "}") Еще можно посмотреть в сторону функций vlax-ldata... |
||||
|
||||
Инженер по системам безопасности Регистрация: 23.11.2003
Рига
Сообщений: 1,099
|
Если рассуждать логически то правильнее было бы сделать так.
Есть определённое оборудование к примеру спринклеры, данные о модели, производителе, расходе воды и т. д. лучше хранить в словаре в соответствующей Х-Записи, а в расширенных данных вносимых в блок спринклера делать только ссылку на эту запись. Таким образом в самой расширенной записи у тебя будет только номер спринклера, способ установки и ссылка на запись в словаре которая будет содержать все данные присущие данной модели. Преймущества таковы: 1. Серьёзно экономим на объеме чертежа. 2. Уменьшается вероятность ошибок при внесении данных, т. к. присваивать модели можно из выпадающего меню которое будет содержать данные из словаря. 3. В Х-Запись словаря можно внести намного больше разнородной информации, без дублирования DXF-групп. Недостатки: Всё это сложнее в реализации. |
|||
|
||||
Thượng Tá Quân Đội Nhân Dân Việt Nam Регистрация: 14.03.2005
44d32'44"С, 33d26'51"В
Сообщений: 13,381
|
Fantomas подсказывает правильное направление - не привязывать полный набор данных к каждому применению оборудования.
Но еще правильнее, чтобы все описательные и прочие данные вообще хранились не в DWG, а в базе данных. Там их можно всегда поддерживать в актуальном состоянии и редактировать независимо от AutoCAD. А данные, хранящиеся в DWG (самом неудобном для редактировании месте, какое можно придумать) будут устаревать и будут плодиться эти ошибки при повторных применениях. А привязывать - только ссылку в расширенных данных на алиас БД и код записи. Однако все мечты о автоматическом специфицировании могут легко разбиться. Для того, чтобы автоматически сосчитать количества чего угодно и сделать разом спецификацию, необходимо, чтобы все, что надо специфицировать, было нарисовано только специальными программами, которые и будут (тем или иным образом) привязвать данные для спецификаций. А это реализуемо в ограниченном числе случаев. Подводку к сплинкеру уже нельзя будет нарисовать простой линией, да и нарисована она должна быть с полной реальной трассой, учитывая все подъемы, изгибы и т.п. И так по каждой мелочевке. А еще ведь многое на чертежах не показывается, а в спецификации включается... |
|||
|
||||
CAD Регистрация: 28.08.2003
Киев
Сообщений: 1,835
|
Согласен с ShaggyDoc&Fantomas (поробуй возрази!).
Если данные лежат в базе, то к вставляемому блоку можно добавить даже самый элементарный атрибутик (уникальный признак - марку), который записан в той самой базе. Причем хоть спринклер, хоть попугай. А далее уже никаких проблем! Получается выдержанная по ГОСТ спецификация. У нас так и сделано. Использование расширенных данных - это конечно круто. Но я не программист, я делаю по инженерному. |
|||
|
||||
Moderator
LISP, C# (ACAD 200[9,12,13,14]) Регистрация: 25.08.2003
С.-Петербург
Сообщений: 39,848
|
> Alan : а это как - "по-инженерному"?
__________________
Моя библиотека lisp-функций --- Обращение ко мне - на "ты". Все, что сказано - личное мнение. |
|||
|
||||
Moderator
LISP, C# (ACAD 200[9,12,13,14]) Регистрация: 25.08.2003
С.-Петербург
Сообщений: 39,848
|
> Alan : Это я в курсе, это не более чем стиль написания команд (если обратил внимание, сам так делаю). Меня-то интересовал кусок кода, который выполняет аналогичные действия. Сейчас уже понимаю, что это коммерческая тайна.
Прошу простить и сильно не бить.
__________________
Моя библиотека lisp-функций --- Обращение ко мне - на "ты". Все, что сказано - личное мнение. |
|||
|
||||
CAD Регистрация: 28.08.2003
Киев
Сообщений: 1,835
|
>kpblc
Цитата:
Вот в начале X28 пишет: Цитата:
Но это же не база! Это же не работа. Это же не тот результат! Блоки с атрибутами, это всё таки ИМХО лучше с точки зрения объема информации, чем к каждому примитиву расширенные данные. |
|||
|
||||
CAD Регистрация: 28.08.2003
Киев
Сообщений: 1,835
|
>Alan Пт Июл 22, 2005 15:10
Добавляю к себе. Чем по мне хорош еще элементарненький блок с элементарненьким атрибутом? А тем что двойной клик дает возможность без Лиспа, Влиспа, Обжект... и т.д. отредактировать марку какого нибудь квадратика. |
|||