Среда программирования Библиотеки C++ (стр. 41 )

Чтобы регистрировать себя, приложение должно сначала проверить, чтобы его имя было уже не в APPID таблице, потому что acdbRegApp () должен быть вызван только однажды в рисунок. Если имя не там, приложение должно регистрировать это; иначе, это может идти вперед и использовать данные.

Следующий типовой кодовый фрагмент показывает типичному использованию acdbRegApp ().

#define APPNAME "Local_Operation_App_3-2"

struct resbuf *rbp;

static char *local_appname = APPNAME;

// The static declaration prevents a copy being made of the string

// every time it’s referenced.

.

.

.

if ((rbp = acdbTblSearch("APPID", local_appname, 0)) == NULL) {

if (acdbRegApp(APPNAME) != RTNORM) { // Some other

// problem

acutPrintf("Can’t register XDATA for %s.",

local_appname);

return BAD;

}

} else {

acutRelRb(rbp);

}

Поиск расширенных данных

Приложение может получить зарегистрированные расширенные данные, вызывая acdbEntGetX () функция, которая является подобной acdbEntGet (). В то время как acdbEntGet () возвращает только данные определения, acdbEntGetX () возвращает оба

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

Названия прошли к acdbEntGetX () должен соответствовать приложениям, зарегистрированным предыдущим запросом к acdbRegApp (); они могут также содержать групповые символы. Если параметр приложений - указатель NULL, запрос к acdbEntGetX () идентичен acdbEntGet () запрос.

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

static struct resbuf appname2 = {NULL, RTSTR},

appname1 = {&appname2, RTSTR},

*working_ent;

strsave(appname1.rstring, "MY_APP_1");

strsave(appname2.rstring, "SOMETHING_ELSE");

.

.

.

// Only extended data from "MY_APP_1" and

// "SOMETHING_ELSE" are retrieved:

working_ent = acdbEntGetX(&work_ent_addr, &appname1);

if (working_ent == NULL) {

// Gracefully handle this failure.

.

.

.

}

// Update working entity groups.

status = acdbEntMod(working_ent);

// Only extended data from registered applications still in the

// working_ent list are modified.

Как типовые показы кода, расширенные данные, отысканные acdbEntGetX() функция может изменяться последующим запросом к acdbEntMod (), также, как acdbEntMod () используется, чтобы изменить нормальные данные определения. (Расширенные данные могут также быть созданы, определяя, это в списке примитива прошло к acdbEntMake ()).

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

ОБРАТИТЕ ВНИМАНИЕ, поскольку строки прошли с приложениями, может включать групповые символы, прикладное имя “*” заставит acdbEntGetX () возвращать все расширенные данные, приложенные примитиву.

Управление использованием памяти расширенными данными

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

ObjectARX обеспечивает две функции, acdbXdSize () и acdbXdRoom (), помогать в управлении памятью, которая простиралась, данные занимают. Когда acdbXdSize () пропускают список буфера результата расширенных данных, это возвращает объем памяти (в байтах) который данные займут; когда acdbXdRoom () пропускают имя примитива, это возвращает остающееся число свободных байтов, которые могут все еще быть добавлены в конец к примитиву.

AcdbXdSize () функция должна читать расширенный список данных, который может быть большой. Следовательно, эта функция может быть медленна, так что рекомендуется, чтобы Вы не вызвали это часто. Лучший подход состоит в том, чтобы использовать это (вместе с acdbXdRoom ()) в обработчике ошибки. Если запрос к acdbEntMod () сбои, Вы можете использовать acdbXdSize () и acdbXdRoom () чтобы выяснить, потерпел ли запрос неудачу, потому что примитив исчерпал расширенные данные, и затем брать соответствующее действие, если это - причина для отказа{*неудачи*}.

Использование Меток в Расширенных данных

Расширенные данные могут содержать метки (группа 1005) чтобы сохранить относительные структуры в пределах рисунка. Один примитив может ссылка другая, сохраняя метку другого примитива в ее расширенных данных. Метка может быть возвращена{*восстановлена;отыскана*} позже и проходить к acdbHandEnt () чтобы получить другой примитив. Поскольку больше чем один примитив могут, ссылка другой, метки расширенных данных не обязательно уникальна; команда AUDIT требует, чтобы метки в расширенных данных были или NULL или допустимые метки примитива (в пределах текущего рисунка). Лучший способ гарантировать, который расширил метки примитива, допустим, должен получить метку упомянутого примитива непосредственно от ее данных определения, посредством acdbEntGet (). ( Значение метки находится в группе 5 или 105.)

К примитивам ссылки в других рисунках (например, примитивы, которые приложены посредством таблицы перекрестных ссылок), Вы могут избегать протестов от РЕВИЗИИ, используя расширенные строки примитива (группа 1000) скорее чем метки (группа 1005), потому что метки перекрестно сосланных примитивов или не допустимы в текущем рисунке или конфликте с допустимыми метками. Однако, если XREF Присоединяется, изменения{*замены*} к XREF Связывают, или объединен с текущим рисунком в другим способом, это - до приложения, чтобы пересмотреть ссылки примитива соответственно.

ОБРАТИТЕ ВНИМАНИЕ, когда рисунки объединены посредством ВСТАВКИ, ВСТАВЬТЕ *, XREF Связывает (XBIND), или частичный DXFIN, метки оттранслированы так, чтобы они стали правильными{*допустимыми*} в текущем рисунке. (Если рисунок прихода не использовал{*нанимал*} метки, новые назначены.) Расширенные метки примитива, которые обращаются{*относятся*} к входящим примитивам, также оттранслированы, когда эти команды вызваны.

Когда примитив помещен на блочном определении (посредством команды BLOCK), примитив в пределах блока назначен новые метки. (Если первоначальный примитив восстановлен с OOPS, это сохраняет его первоначальные метки.) значение любых меток расширенных данных остается неизменным. Когда блок вз (с, ВЗРЫВАЮТ), метки расширенных данных оттранслированы, способом, подобным пути, которым они оттранслированы, когда рисунки объединены. Если метка расширенных данных обращается{*относится*} к примитиву не в пределах блока, это неизменно; но если метка расширенных данных обращается{*относится*} к примитиву в пределах блока, это назначено

Значение метки нового (вырезанного) примитива.

Xrecord Объекты

Xrecord объект - встроенный объектный класс с именем DXF “XRECORD”, который сохраняет и управляет произвольными потоками данных, представ внешне в результате буферизуют список, составленный из групп DXF с “ объект нормали ” группы (то есть не - xdata коды группы), в пределах от 1 до 369.

ПРЕДУПРЕЖДЕНИЕ! Xrecord объект разработан{*предназначен*} в пути, который не будет оскорблять более ранние версии AutoCAD; однако, xrecord объект исчезнет при создании DXF файла от предварительного выпуска 13c4 уровень AutoCAD.

Xrecord объекты - универсальные объекты, предназначенные для использования приложениями ObjectARX и AutoLISP. Этот класс позволяет приложениям создавать и сохранять произвольные объектные структуры произвольных списков буфера результата не-графической информации, полностью отделяются от примитивов. Корневой владелец для всех определенных приложением объектов является или словарью имен объектов, которая принимает любой тип AcDbObject как вход, включая AcDbXrecord, или словарь расширения любого объекта.

Приложения, как ожидается, будут использовать уникальные названия{*имена*} входа в словари имен объектов. Логика использования словари имен объектов или имени входа словаря расширения{*продления*} подобна таковому имени REGAPP. Фактически, REGAPP названия{*имена*} совершенен для использования как названия{*имена*} входа при добавлении в конец определенных приложением объектов к базе данных или специфическому объекту.

Использование xrecord объектов представляет существенное упрощение относительно текущей практики назначения xdata к примитивам. Поскольку xrecord объект не должен быть связан с примитивом, Вы больше не должны создать фиктивные примитивы (фиктивные примитивы часто использовались, чтобы обеспечить большее количество участка памяти для xdata), или примитивов на закрепемых уровнях.

Приложения теперь способны делать следующее:

Защищают информацию от неразборчивой чистки или размораживания уровней, который является всегда угрозой неграфической информации, сохраненной в data. Используют новые поля (330-369 ссылки / указателя монопольного использования объекта, чтобы обслужить{*поддержать*} внутренние ссылки объекта базы данных. Произвольные значения метки полностью освобожденны от механики трансляции объекта ID. Это оппозиционно настроено в отношении 1005 xdata групп, которые оттранслированы в некоторых случаях, но не в других. Остаются незатронутым 16КБ в объект xdata предел способности{*вместимости*}. Этот объект может также использоваться вместо xdata на определенных примитивах и объектах, если один так пожелания, с пониманием, что независимо от того, где Вы сохраняете xrecord объекты, они не имеют никакого встроенного предела размера, другого чем предел 2 ГБАЙТА, наложенных подписанным 32-разрядным целочисленным диапазоном.

В случае объектно - определенного состояния, xrecord объекты хорошо удовлетворены для сохранения больших количеств сохраненной информации, в то время как xdata лучше удовлетворенный для меньших количеств данных.