[АлексЮстасу]

Пардон за наивные вопросы - только пытаюсь знакомиться с xdata. Пишу в "Программирование", поскольку ответить смогут только программисты?
Пока имею возможность рассматривать xdata только с помощью команд xdata и xdlist из Express Tools.
1. Единое описание xdata у однотипных объектов не предусмотрено? Т.е. в принципе каждая отдельная xdata потенциально уникальна? Например, одна xdata "Труба", у одного графического элемента, может иметь один набор полей (допустим, для материала труб и диаметра), а другая "Труба" же, но у другого элемента может иметь совсем другой набор полей и числом, и типами полей (допустим, для назначения трубы, толщины стенок, предельного давления, сечения)? Тогда получается, что для анализа и манипулирования данными из xdata необходимо самостоятельно описывать структуры и состав xdata где-то вовне dwg? Но как быть с тем, что это почти бесполезно. Ведь ничто не ограничивает различие числа, типов и порядка следования полей у xdata для данных однотипных объектов?
2. Как описывать в xdata целочисленные поля для чисел больше 32767?
В xdata для целочисленных значений предусмотрены типы int и long.
Если задать для поля типа int или поля типа long число больше 32767, то появляется сообщение, что требуется целое значение до 32767.
Других типов целочисленных полей в xdata не предусмотрено.
3. Как идентифицировать поля данных в xdata - для каких данных какое поле? Ни при описании полей при команде xdata, ни при просмотре их с помощью xdlist не видно никаких идентификаторов полей. Единственное - порядок следования полей?
Допустим, присоединяю xdata к элементу с тремя полями типа str, символьными, описанными в последовательности: поле1, поле2, поле3. Но с помощью xdlist виден порядок полей обратный:

* Registered Application Name: XDATA_1 * Code 1002, Starting or ending brace: { * Code 1000, ASCII string: содержание_поля_3 * Code 1000, ASCII string: содержание_поля_2 * Code 1000, ASCII string: содержание_поля_1 * Code 1002, Starting or ending brace: }

Как при этом найти нужное поле?

Или эти вопросы от особенности не самих xdata, а особенность работы команд xdata и xdlist из Express Tools?

[Сергей812]

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

насколько помню, у ТС для этого есть молодой программист)

[gomer]

Сообщение от Сергей812 у ТС для этого есть молодой программист)

А Я забыл жешь

[Александр Ривилис]

По поводу использования LDATA (т.е. vlax-ldata-put/vlax-ldata-get). Не рекомендую ими пользоваться тем, кто собирается программировать не только на VisualLisp. Средства ObjectARX/AutoCAD .NET API не работают с такими данными. Точнее работа с такими данными совсем не документирована, используется пользовательский класс объекта vlo_VL, у которого нет публичного API. Если копнуть в глубину, то это выглядит так:

[АлексЮстасу]

Сообщение от Сергей812 терпите - вы уже начинающий программист)

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

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

[Сергей812]

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

А зачем из программистов что-то вытягивать? Ставите четко описанную задачу, на каких машинах (по конфигурации), каких версиях AutoCAD все это должно работать и т.д. А дальше головная боль программистов - как реализовывать и как потом поддерживать. А вы пытаетесь влезть в программирование, причем выхватывая какие то отдельные куски задачи. Или у вас не программисты, а обыкновенные кодеры-кнопкодавы.

[АлексЮстасу]

Сообщение от Александр Ривилис По поводу использования LDATA (т.е. vlax-ldata-put/vlax-ldata-get). Не рекомендую ими пользоваться тем, кто собирается программировать не только на VisualLisp. Средства ObjectARX/AutoCAD .NET API не работают с такими данными. Точнее работа с такими данными совсем не документирована, используется пользовательский класс объекта vlo_VL, у которого нет публичного API.

Как же быть, если программер, кроме c++, писать ни на чем не собирается? Может быть в ранних версиях ObjectARX есть больше?
Необходимо не так много возможностей: создания определений нужных записей, редактирования определений, удаления определений, просмотра записей, ввода значений в записи. Или только кажется, что нужно немногое?

Сообщение от Сергей812 А зачем из программистов что-то вытягивать? Ставите четко описанную задачу

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

[Сергей812]

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

Расширяемость и реализуемость можно заложить на уровне ТЗ. Тем больше времени потратите на обдумывание ТЗ, тем меньше придется приделывать к программе "костылей" при новых возникающих функциональных потребностях.

[Александр Ривилис]

Сообщение от АлексЮстасу Как же быть, если программер, кроме c++, писать ни на чем не собирается? Может быть в ранних версиях ObjectARX есть больше? Необходимо не так много возможностей: создания определений нужных записей, редактирования определений, удаления определений, просмотра записей, ввода значений в записи. Или только кажется, что нужно немногое?

Просто не пользоваться LDATA (которая есть некая хитрая разновидность Dictionary), а напрямую пользоваться Dictionary/XRecord если объема XDATA (16Кбайт на объект для всех приложений) по каким-то причинам недостаточно.
В любом случае создать LDATA (т.е. выполнить аналог vlax-ldata-put) средствами ObjectARX врядли удастся.

[ShaggyDoc]

Просто не пользоваться LDATA (которая есть некая хитрая разновидность Dictionary), а напрямую пользоваться Dictionary/XRecord

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

ru-dictvar-clear-all
ru-dictvar-clear-data
ru-dictvar-about-dlg
ru-dictvar-copyright-data
_ru-dictvar-add-new-dict
_ru-dictvar-add-new-var-name
_ru-dictvar-clear-value
_ru-dictvar-copyright
_ru-dictvar-gen-var-list
_ru-dictvar-get-copyright
_ru-dictvar-get-dict
_ru-dictvar-get-sym
_ru-dictvar-list-to-pickset
_ru-dictvar-name
_ru-dictvar-pickset-to-list
_ru-dictvar-regen-var-list
_ru-dictvar-remove-var
_ru-dictvar-set-var-data
ru-dictvar-get-data
ru-dictvar-list-all-var
ru-dictvar-set-data

ru-xrecord-add
ru-xrecord-delete
ru-xrecord-get
ru-xrecord-rebuild

ru-xdata-add-for-ent
ru-xdata-add-list-bracket
ru-xdata-write-for-ent
ru-xdata-get-for-pline-vertex
ru-xdata-get-reg-apps
ru-xdata-get-ruclass-by-layer-name
ru-xdata-get-ruclass-for-active-layer
ru-xdata-get-ruclass-for-all-layers
ru-xdata-get-ruclass-for-layer-obj
ru-xdata-read-for-ent
ru-xdata-rem-for-selection
ru-3d-xdata-rucad-regapp
ru-xdata-rucad-regapp

Тут "тщательнЕе надо, тщательнЕе" (С)

[АлексЮстасу]

Сообщение от Александр Ривилис Просто не пользоваться LDATA (которая есть некая хитрая разновидность Dictionary), а напрямую пользоваться Dictionary/XRecord если объема XDATA (16Кбайт на объект для всех приложений) по каким-то причинам недостаточно. В любом случае создать LDATA (т.е. выполнить аналог vlax-ldata-put) средствами ObjectARX врядли удастся.

В принципе, на один элемент по моим прикидкам (для картографических задач и не только) в среднем будет приходиться всего по 1.5-2 определения ("Application Name", XRecord), и только в небольшом проценте случаев до 5-7. Очень многие специалисты вообще противники определять один элемент больше, чем как один объект реальности, хотя, мне этот подход кажется некорректным. Т.е. число "приложений" прогнозируется небольшим в среднем и незначительным в предельном варианте.
16 кб - в принципе немало. 160 полей по 100 символов.
Тем не менее ограничение объема в 16 кб (а Сергей812 считает, что реально в 1 кб) все-таки для общего случая кажется рискованным.

По поводу XRecord мне еще не понятно, из чего состоит из собственное описание, какие у них есть возможности и ограничения, и что ими можно определить.

----- добавлено через ~5 мин. -----

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

Согласен. В нашем сделанном под Map варианте получилось до 50 команд-программок - для полноценного решения без полноты, разнообразия возможностей не обойтись.

[Александр Ривилис]

Сообщение от АлексЮстасу Тем не менее ограничение объема в 16 кб (а Сергей812 считает, что реально в 1 кб) все-таки для общего случая кажется рискованным.

Это он ссылается на мнение Kean Walmsley, которому я доверяю, но проверяю. Вообще-то ограничение в 1Кб, это всё-таки перебор и реальных предпосылок именно для этого ограничения нет. С другой стороны если на каждый примитив добавить по 16Кбайт своей информации, то чертеж вырастет по объему в сотни раз.

Сообщение от АлексЮстасу По поводу XRecord мне еще не понятно, из чего состоит из собственное описание, какие у них есть возможности и ограничения, и что ими можно определить.

Ограничений по объему практически никаких. Ограничение на длину строки для строковых и битовых данных - 255 байт. Можно в нём хранить строки, целые и плавающие числа, точки, имена других объектов, битовые поля. Структуру определяешь сам.

[Сергей812]

1Кб - Не ограничение, а рекомендация от Kean Walmsley. Если переводить #14:

xData хороши для объема данных около 1Кб, а если нужно больше - то рекомендую использовать ExtDicts + XRecords. Так как слишком велик риск использования расширенных данных для большего объема (более 1 кб/приложение).

[VVA]

еще пару ссылок
http://books.google.by/books?id=nByA...page&q&f=false
http://autolisp.ru/2012/04/06/dictionaries/

[АлексЮстасу]

Сообщение от Александр Ривилис Вообще-то ограничение в 1Кб, это всё-таки перебор и реальных предпосылок именно для этого ограничения нет

Сообщение от Сергей812 xData хороши для объема данных около 1Кб

Почему не 2 кб, не 0.5? Должна быть какая-то аргументация. Допустим, до 1 кб пишется в надежное место, а больше - где данные могут путаться или теряться. Или еще что.

Еще интересно влияние расширенных данных на скорость работы Автокада. Ведь может же быть, что РД меньше влияют на скорость, чем аналогичные объемом графические данные?

Сейчас сделал эксперимент: создал полилинию, присоединил к ней с помощью XDATA.lsp из Express Tools расширенные данные в 30 символьных полей по 100 символов. Размножил этот элемент до 10000 штук. Сделал аналогичную полилинию в другом файле, и размножил ее до 10000 штук.
В файле с XData должно быть 10 000*30*100=30 000 000 байт занято РД. Это 30 мб? (Умею считать как топограф, но не как программист ) Размер же этого файла - 1 291 кб.
Размер файла с аналогичными элементами, но без XData - 700 кб.
Т.е. файлы различаются всего на 0.5 мб. Остальные 29.5 мб РД куда делись? Как-то оптимизировались за счет полной их одинаковости? Или свернулись за счет какого-нибудь "шестнадцатеричного представления"?
Кроме того, XDLIST.lsp время от времени выдавал, что у одного элемента с этими РД свободно примерно 13 кб, то пишет, что свободно 10 кб. Эти 3 кб разницы индикации свободного места в РД откуда берутся? Чаще 10 кб. Может быть Kean Walmsley что-то подобное имел в виду?

Кстати, на моей машине время выделения всех элементов что в файле с РД, что в файле без РД одинаковое - 20 секунд.

Файлы для интереса приложил.

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

АлексЮстасу, dwg является не только закрытым (то бишь проприетарным) форматом, но еще и архивом в некоторой степени. Ты попробуй сохранять не в dwg, а в dxf версии "пораньше" - и только потом выполняй сравнение.

[Do$]

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

1. XDATA, расширенные данные:

+ Есть инструменты в Express Tools для их просмотра и редактирования
+ При создании копии объекта, копируется вместе с ним.
+ Можно использовать эти данные в фильтре выбора объектов с помощью SSGET
+ Может содержать данные, которые модифицируются вместе с объектом встроенными средствами - насколько я помню, пересчитываются данные под определенными кодами в зависимости от поворота или масштаба объекта.

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

Назначение: хранение небольших по объему данных с заранее известным объемом. Например - идентификатор связанной с объектом записи во внешней базе данных, точка для дополнительной геометрии объекта при переопределении его отрисовки и т.п.
Использую только для тех объектов, которые создаются моими приложениями. То есть, я точно знаю, что они не содержат других расширенных данных.

2. Object Extension Dictionary, словарь расширения объекта. Принадлежит конкретному объекту чертежа. Может содержать как вложенные словари, так и записи в виде XRECORD.

+ Нет ощутимых ограничений по объему

- Не имеет возможностей XDATA.

Назначение: хранение данных об объекте, размер которых может изменяться. Например - коллекции точек, текстовые описания и т.п.

3. Named Object Dictionary, NOD, словарь именованных объектов чертежа. Один единственный на весь чертеж. Может содержать как вложенные словари, так и записи в виде XRECORD.

+ Нет ощутимых ограничений по объему

- В нем изначально уже есть много словарей, созданных программистами Autodesk, поэтому, нужно быть аккуратным и не нарушить в нем ничего.

Назначение: централизованное хранение информации об объектах чертежа, хранение не связанной с объектами чертежа информации.

[Сергей812]

Сообщение от АлексЮстасу Кроме того, XDLIST.lsp время от времени выдавал, что у одного элемента с этими РД свободно примерно 13 кб, то пишет, что свободно 10 кб. Эти 3 кб разницы индикации свободного места в РД откуда берутся? Чаще 10 кб. Может быть Kean Walmsley что-то подобное имел в виду?

Об этом знают достоверно только разработчики Autodesk) Я бы просто не стал работать на граничных условиях, чтобы потом не отлавливать в программе неожиданные ошибки. Вы хотите извлечь из xData по максимум - тогда не забудьте реализовать методы удаления расширенных из чертежа. Чтобы потом смежники не удивлялись размерам файла.

----- добавлено через ~9 ч. -----
И еще представьте вариант - вам нужно скопировать свойства с объекта с одного чертежа на объект на другом чертеже - будете жонглировать чертежами?

[АлексЮстасу]

1. Можно без ограничений ввести в XData строковое поле с длиной больше 255. Пробовал и 257, и 270, и 300 символов. Пробовал с помощью XDATA.lsp из Express Tools. И XDLIST.lsp подтверждала, что такие строки без обрезания созданы. Сохранял-открывал - поля с длиной больше 255 символов сохранялись со всем содержимым.
И только Audit их обрезал до 255
2. Создал XData с 20-ю строками по 250 символов в каждой. Т.е. занял 5 кб. А XDLIST сообщает:

Object has 6316 bytes of Xdata space available.

Т.е., якобы, занято 10 кб. Опять определяется, что занято в два раза больше, чем реально введено.
Добавил еще 20 строк по 250 символов. Т.е. в сумме данные составили 10 кб. Сообщили:

Insufficient Xdata space available on object- no new Xdata appended.

Кто-нибудь с такой разницей между реальным и сообщаемым размером содержимого XData сталкивался? Или это XDATA.lsp неправильно создает, а XDLIST.lsp из Express Tools неправильно сообщает?

[Сергей812]

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

[АлексЮстасу]

Сообщение от Сергей812 всегда существуют накладные расходы.. кроме объема сохраняемых данных..

Накладные расходы в 50% - это круто.
Сохранил те файлы по совету Кулик Алексей aka kpblc в dxf: без XData - 4 мб, с XData - 36 мб. Из них 30 мб - содержание XData, на "накладные" остается 2 мб.
Если реальные издержки XData составляют примерно 7%, то чем объяснить удвоение расходов допустимого объема, показываемого XDATA.lsp и XDLIST.lsp? Там не просто сообщается о большем, чем занято объеме, но и отказывается присоединять еще данные. Косяки XDATA.lsp и XDLIST.lsp? Или еще что-то?