Логотип сайта поддержки пользователей САПРО сайте поддержки пользователей САПР Translate to:

Хранение не графических (non-graphic) данных при написании приложений под AutoCAD.

В статье рассмотрены различные варианты хранения не графических данных при написании приложений под Автокад с использованием ObjectARX. Под non-graphic будем понимать любую информацию, которая должна быть связана тем или иным образом с конкретным проектом (под проектом можно для упрощения понимать чертеж) и не имеет графического отображения. Приведу несколько примеров non-graphic:

Допустим, Ваше приложение строит карту. Построение карты всегда выполняется в соответствии с заданным масштабом, так вот масштаб и будет примером non-graphic, так как он должен задаваться и сохраняться вместе с чертежом (проектом). Другим примером non-graphic могут послужить какие-либо коэффициенты, связанные с какими-либо объектами чертежа и используемые при расчетах. На самом деле, любой программист пишущий под AutoCAD обязательно сталкивался, или, если не сталкивался, то обязательно сталкнется, с проблемой хранения non-graphic. Выбор верной стратегии хранения non-graphic во много определит весь ход написания приложения, поэтому перед началом разработки окончательно определитесь с вариантом. Ниже предложены варианты, которыей применялись в тех или иных случаях и проверенны на личном опыте, дается оценка положительных и отрицательных их сторон. Следует отметить, что предложенные варианты, наверняка, не являются исчерпывающими.

Вариант 1. Текстовые файлы.

Наиболее простым способом хранения non-graphic является их запись в текстовые файлы. Для каждого нового проекта Вы создаете новый текстовой файл, в котором хранятся все Ваши non-graphic (текущие значения коэффициентов, масштабы, параметры хода расчетов и.т.д., и.т.п.). Данный вариант имеет смысл применять в случае, если связь между non-graphic и чертежом прямая: по значениям non-graphic выполняются построения или вычисления, а дальнейшее редактировании чертежа не влияет на non-graphic. Например: в текстовом файле хранятся значения силы поля в конкретных точках которые остаются неизменными на протяжении всего времени работы с проектом. Недостатком метода, является то, что необходимо устанавливать связь между созданным текстовым файлом и файлом dwg Автокада. Каждый раз при передаче файлов dwg, Вам придется передавать текстовые файлы с non-graphic. Установить связь между файлами можно двумя способами: первый способ заключается в том, что в текстовом файле Вы создаете ссылку на файл dwg, например:

dwgname=”c:\projects\pr11.dwg”.

В этом случае вся смысловая нагрузка понятия “Проект” ложится на Ваш текстовой файл, а следовательно все операции по открытию/закрытию проектов будут производится над текстовым фалом. Второй способ подразумевает, что для каждого отдельного проекта будет создаваться отдельный каталог в котором будут храниться как dwg так и Ваши текстовые файлы, программа должна будет определять местоположение вашего dwg-файла и брать non-graphic из файла, лежащего в этом же каталоге. Операции по открытию/закрытию проектов будет заключаться в указании каталогов.

Вариант 2. Использование класс AcDbXrecord.

Класс AcDbXRecord является хранилищем данных, способным содержать до 2 Гб информации. Механизм ввода-вывода информации построен на использовании структуры resbuf. Структура поддерживает все стандартные группы кодов данных Автокада, что означает, возможность хранение идентификаторов объектов и любого из четырех его типов (hard owner, soft owner, hard pointer, soft pointer). Использование AcDbXRecord имеет смысл в случае, когда необходимо все данные о проекте держать в dwg файле, т.е. проекто должен быть целостным. Также одним из преимуществ этого варианта является то, что данные xrecord доступны программам, написанным на ADSRX и AutoLISP. Недостатком варианта хранение non-graphic можно считать использование структуры resbuf для ввода-вывода, что усложняет код. Так, например, код для записи строки текста, целого числа и числа с плавающей точкой будет выглядеть следующим образом:

            AcDbXrecord *pXrec = new AcDbXrecord;

            AcDbObjectId xrecObjId;

            struct resbuf *pHead;

            Cstring S=”String2”;  

            Int I;

            double dVal=12.435;

            pHead = acutBuildList( 

            AcDb::kDxfText, S,

            AcDb:: kDxfInt16,i, 

            AcDb::kDxfReal,dVan,0);

            pXrec->setFromRbChain(*pHead);

            acutRelRb(pHead);

Чтение данных выполняется по средствам вызова функции класса AcDbXrecord

Acad::ErrorStatus rbChain(resbuf** ppRb,AcDbDatabase* auxDb = NULL)

Дальнейшая работа с данными требует итерации по элементам структуры ppRb. Если Вы остановите свой выбор на использовании этого варианта хранения non-graphic, то советую обзавести собственными сервисными функциями которые будут читать и писать Ваши данные, что-то вроде

setPowerField(double dPf); - установка глобального параметра силового поля для всего проекта.

getPowerField(double& dPf); - чтение глобального параметра силового поля для всего проекта.

Вариант 3. Создание классов, унаследованных от AcDbObject.

Метод заключается в создании новых классов со специфическим набором свойств, отвечающим Вашим non-graphic. Так например, если Вам необходимо установить набор опций для Вашего проекта, создайте новый класс и объявите в нем переменные, отвечающие этим опциям. Далее создайте один объект этого класса при создании нового проекта и добавьте его в графическую базу данных Автокада. Удобство этого метода заключается в относительно простом способе доступа к объектам посредствам стандартной итерации а также в организации данных, отвечающей непосредственно Вашим требованиям. Недостатком является то, что для доступа к объектам скомпилированный файл Вашего нового класса (dbx-файл) должен быть обязательно загружен, а это означает, что распространяя проект, Вам необходимо будет распространять и dbx-файл.



Copyright © Сайт поддержки пользователей САПР by Victor Tkachenko