[X28]

Категорически приветствую всех присутствующих!

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

Разобрался с Xdata, которая в Express tools.
Однако способом, написанным в xdata.lsp можно добавить только список с ключами 1000 1003 1005 1010 1012 1013 1041 1042 1070 1071, и больше никакие.
Причем тип данных для каждого ключа где-то определен. Так например для тпары с ключем 1000 (1000. XXXX) XXXX - только строка, больше никакие значения акад не принимает. Не принимает он и произвольные ключи. bad DFX group и все тут!
Что сделать чтоб можно было засунуть в расширенные данные списки вида (1 . 30)(2 . 44) (3 . 45) и т. п???

Или может зря я в расширенные данные подался? Может есть другой алгоритм привязки данных к определенному примитиву??? Буду рад услышать любые мнения.

ЗЫ Acad 2004 у меня.

[Лентяй]

В чем проблема-то? В спецификацию переносятся объекты типа "строка", т.е. код 1000. ActiveX-ом вытаскиваешь соот-е свойство, преобразуешь его, если надо, в текст и загоняещь в Xdata с кодом 1000. Ниже - пример программы формирования выносок трубопроводов. Обрати внимание на использование слоя для описания назначения трубопровода.

(defun pct:getxdt (obj / sz serv mat vls xtp xdt) (vla-GetXData obj "INFO" 'xtp 'xdv) (if xdv (progn (setq vls (mapcar '(lambda (x) (vlax-variant-value x)) (cdr (vlax-safearray->list xdv))));setq (strcat (car vls) "-" (cadr vls) "(" (caddr vls) ")"));progn (progn (if (null sz0) (setq sz0 "")) (if (null mat0) (setq mat0 "")) (initget "Yes No") (setq kw (getkword "\n Service by Layer [Yes/No]: ? <Yes>")) (if (null kw) (setq kw "Yes")) (setq serv (if (= kw "Yes") (vla-get-layer obj) (getstring (strcat "\nEnter pipe service for " (vla-get-layer obj) ": "))) sz (getstring (strcat "\nEnter pipe size for " serv ": <" sz0 ">"))) (if (= sz "") (setq sz sz0)) (setq sz0 sz) (setq mat (getstring (strcat "\nEnter pipe material for " serv ": <" mat0 ">"))) (if (= mat "") (setq mat mat0)) (setq mat0 mat) (setq xtp (vlax-make-variant (vlax-safearray-fill (vlax-make-safearray vlax-vbInteger '(0 . 3)) '(1001 1000 1000 1000))) vls (mapcar '(lambda (x) (vlax-make-variant x vlax-vbString)) (list "INFO" sz serv mat)) xdv (vlax-safearray-fill (vlax-make-safearray vlax-vbVariant '(0 . 3)) vls));setq (vla-SetXData obj xtp xdv) (strcat sz "-" serv "(" mat ")"));progn );if );defun

[Лентяй]

В чем проблема-то? В спецификацию переносятся объекты типа "строка", т.е. код 1000. ActiveX-ом вытаскиваешь соот-е свойство, преобразуешь его, если надо, в текст и загоняещь в Xdata с кодом 1000. Ниже - пример программы формирования выносок трубопроводов. Обрати внимание на использование слоя для описания назначения трубопровода.

Код:

[Выделить все]

(defun pct:getxdt (obj / sz serv mat vls xtp xdt)
  (vla-GetXData obj "INFO" 'xtp 'xdv)
  (if xdv (progn 
      (setq vls (mapcar '(lambda (x) (vlax-variant-value x))
			(cdr (vlax-safearray->list xdv))));setq
      (strcat (car vls) "-" (cadr vls) "(" (caddr vls) ")"));progn
    (progn (if (null sz0) (setq sz0 "")) (if (null mat0) (setq mat0 ""))
      (initget "Yes No")
      (setq kw (getkword "\n Service by Layer [Yes/No]: ? <Yes>"))
      (if (null kw) (setq kw "Yes"))       
      (setq serv (if (= kw "Yes") (vla-get-layer obj)
		   (getstring (strcat "\nEnter pipe service for " (vla-get-layer obj) ": ")))
	    sz (getstring (strcat "\nEnter pipe size for " serv ": <" sz0 ">")))
      (if (= sz "") (setq sz sz0)) (setq sz0 sz)
      (setq mat (getstring (strcat "\nEnter pipe material for " serv ": <" mat0 ">")))
      (if (= mat "") (setq mat mat0)) (setq mat0 mat)
      (setq xtp (vlax-make-variant (vlax-safearray-fill
		     (vlax-make-safearray vlax-vbInteger '(0 . 3)) '(1001 1000 1000 1000)))
	    vls (mapcar '(lambda (x) (vlax-make-variant x vlax-vbString))
			 (list "INFO" sz serv mat))
	    xdv (vlax-safearray-fill (vlax-make-safearray vlax-vbVariant '(0 . 3)) vls));setq
      (vla-SetXData obj xtp xdv)
      (strcat sz "-" serv "(" mat ")"));progn
  );if
);defun

[X28]

Про спецификацию понятно... там можно обойтись только текстом. (это я уже почти сделал)
Задача несколько шире - хочу чтоб примитив был не просто примитивом, а именно элементом со своими параметрами.

Т. е. например есть примитив "блок". Например это спринклер. В расширенные данные хотелось бы внести
1. - название (для спецификации) тип "строка"
2. - производитель (для спецификации) тип "строка"
3. - расход воды (для рассчета) - тип "число"
4. - вариант установки, розеткой вверх/вниз (для рассчета и автоматической отрисовки аксонометрии) - тип "логический"
5. - ссылка на блок_условное_изображение_на_схеме (для автоматической отрисовки аксонометрии) - тип "строка"

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

Как все это в него запихнуть? Единственное что мне пришло на ум - все данные преобразовывать в строку вида "| 1.ХХХ | 2.XXX | 3.XXX | 4.XXX| 5.XXX |", засовывать эту строку в 1000 тип, а потом при каждой надобности её "раскодировать". Но мне кажется что такая система будет работать очень медленно.

Есть свежие идеи на эту тему?

[MIP]

>>X28
Может Вам лучше работать с присоединенными данными, как со словарями? Формируете список данных в виде списка ((1 25) (2 труба) (3 200) (4 25) и т.д) или ((номер 1) (тип труба) (диаметр 200) (расход 25)), Вам выбирать, но суть первой позиции в списках возможность поиска нужного значения по метке, затем присоединяете их к примитиву при помощи vlax-idata-put (нужна утилита на Лисп для удобства работы) с кодом словаря (Задается пользователем для последующего извлечения необходимых данны из словаря). В последующем эти данные можно извлекать из объекта при помощи vlax-idata-get и нахождить в списке необходимых данных (опять же нужна соответствкующая утилита на Лисп) остальна работа уже по потребностям!
Причем эти данные могут быть как строковые так и числовые, для списка разницы нет, тем более их всегда можно конвертировать.

[BigBrother]

Можно не формировать составную строку с идентификатором типа данных, а предварять ее этим идентификатором записанным в группу 1070 - (1070 . 1)(1000 . "Name")(1070 . 2)(1000 . "Description") и т.д.
Соответственно задача формирования|разбора данных упрощается.
Еще можно группировать данные, т.е. вводить аналог списка по группе (1002 . "{") ...... (1002 . "}")
Еще можно посмотреть в сторону функций vlax-ldata...

[X28]

Vlax-ldata Значица...

Спасибо! Теперь знаю в какую сторону копать.

[{Smirnoff}]

Если рассуждать логически то правильнее было бы сделать так.

Есть определённое оборудование к примеру спринклеры, данные о модели, производителе, расходе воды и т. д. лучше хранить в словаре в соответствующей Х-Записи, а в расширенных данных вносимых в блок спринклера делать только ссылку на эту запись.

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

Преймущества таковы:

1. Серьёзно экономим на объеме чертежа.
2. Уменьшается вероятность ошибок при внесении данных, т. к. присваивать модели можно из выпадающего меню которое будет содержать данные из словаря.
3. В Х-Запись словаря можно внести намного больше разнородной информации, без дублирования DXF-групп.

Недостатки:

Всё это сложнее в реализации.

[ShaggyDoc]

Fantomas подсказывает правильное направление - не привязывать полный набор данных к каждому применению оборудования.

Но еще правильнее, чтобы все описательные и прочие данные вообще хранились не в DWG, а в базе данных. Там их можно всегда поддерживать в актуальном состоянии и редактировать независимо от AutoCAD. А данные, хранящиеся в DWG (самом неудобном для редактировании месте, какое можно придумать) будут устаревать и будут плодиться эти ошибки при повторных применениях.

А привязывать - только ссылку в расширенных данных на алиас БД и код записи.

Однако все мечты о автоматическом специфицировании могут легко разбиться. Для того, чтобы автоматически сосчитать количества чего угодно и сделать разом спецификацию, необходимо, чтобы все, что надо специфицировать, было нарисовано только специальными программами, которые и будут (тем или иным образом) привязвать данные для спецификаций. А это реализуемо в ограниченном числе случаев.

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

[Alan]

Согласен с ShaggyDoc&Fantomas (поробуй возрази!).
Если данные лежат в базе, то к вставляемому блоку можно добавить даже самый элементарный атрибутик (уникальный признак - марку), который записан в той самой базе.
Причем хоть спринклер, хоть попугай. А далее уже никаких проблем! Получается выдержанная по ГОСТ спецификация. У нас так и сделано.
Использование расширенных данных - это конечно круто. Но я не программист, я делаю по инженерному.

[Кулик Алексей aka kpblc]

> Alan : а это как - "по-инженерному"?

[Alan]

>kpblc См. живых классиков (Зуев-Полещук) "САПР на базе..." стили программирования. стр. эдак 197

[Кулик Алексей aka kpblc]

> Alan : Это я в курсе, это не более чем стиль написания команд (если обратил внимание, сам так делаю). Меня-то интересовал кусок кода, который выполняет аналогичные действия. Сейчас уже понимаю, что это коммерческая тайна.
Прошу простить и сильно не бить.

[Alan]

>kpblc

Меня-то интересовал кусок кода, который выполняет аналогичные действия. Сейчас уже понимаю, что это коммерческая тайна.

Какой кусок? Если по Xdata, то Лентяй написал кусок, можно смотреть. Если по нашему "инженерному" способу, то тоже самое (без vla) делает _attext с шаблоном, что НЕ есть коммерческая тайна. Зато потом: база оборудования; база проектов; отчет, - вот это ИМХО самое ценное. Создание и ведение базы, получение отчета на стандартных бланках и т.д. Ты же видел конечный продукт - спецификацию.?
Вот в начале X28 пишет:

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

Мы вначале имели похожий вариант (блоки с атрибутами с инфой для спецификациии) и получали легким нажатием на кнопку спецификации (как раз по ВК) в Автокаде.
Но это же не база! Это же не работа. Это же не тот результат!
Блоки с атрибутами, это всё таки ИМХО лучше с точки зрения объема информации, чем к каждому примитиву расширенные данные.

[Alan]

>Alan Пт Июл 22, 2005 15:10
Добавляю к себе.
Чем по мне хорош еще элементарненький блок с элементарненьким атрибутом? А тем что двойной клик дает возможность без Лиспа, Влиспа, Обжект... и т.д. отредактировать марку какого нибудь квадратика.