Тема: undo в customEntity

Здравствуйте!
Создаю CustomEntity (производный от AcDbEntity), в котором содержаться ссылки на размеры (AcDbAlignrdDimension) и на другие созданные примитивы.
Например, сборка или деталь, в которую входят другие детали и размеры. Ссылки храняться как список AcDbObjectId и на детали и на размеры. При удалении функция удаляет деталь, ссылка на которую  хранится в главном примитиве (сборке), престраивает размеры. Все работает нормально. При многократном тестировании все тоже все нормально.  Но при вызове команды undo генерируется исключение isValid(i), и удаленный примитив не возвращается назад. Почему??? Может быть какую функцию забыл перегрузить, которая за undo отвечает???
Никак не могу понять, почему в одну сторону процесс идет нормально, а в другую сторону с ошибкой.
Большое спасибо, Алексеев

Re: undo в customEntity

Может быть в тему, может быть нет
в dwgInFields
рекомендую добавить очистку массива перед заполнением

Re: undo в customEntity

За undo отвечают ф-и dwgIn\dwgOutFields. При работе undo им передается undoFiler и изменяется порядок вызова.
Если например список объектов сохраняется как вектор то код должен выглядеть следующим образом:

Acad::ErrorStatus UnisPipeH::dwgInFields(AcDbDwgFiler* pFiler)
{
assertWriteEnabled();
Acad::ErrorStatus es;
// Call dwgInFields from AcDbPolyline
if((es = AcDbPolyline::dwgInFields(pFiler)) != Acad::eOk) return es;
    
// Read version number.
Adesk::UInt16 version;
pFiler->readItem(&version);
if(version > VERSION)  return Acad::eMakeMeProxy;
// Read the data members.    
Adesk::Int16 Len = 0, val;
pFiler->readItem(&Len);//чтение количества ObjectId
m_ObjectIdVec.resize(Len);[b]! здесь ставим размер вектора ровно таким как нужно[/b]
for(int i=0;i<Len;i++ )//чтение ObjectId
...

Главным является вызов resize.
Если это не поможет значит причиной является способ удаления, но об этом сказать не могу ничего smile
"Найти кремниевые наконечники стрел палеолита легче, чем ответ на этот вопрос" Шерлок Холмс.

Re: undo в customEntity

Спасибо Большое за отклик, я решил эту проблему следующим образом. Для своего объекта перегрузил фунцию subErase, параметром которой служитAdesk::Booleean pErasing, она вызывается при удалении объекта (pErasin = true) и при его восстановлении по undo(pErasing = false). Пришлось переписать функции удаления примитивов, так чтобы они работали в обе стороны. Все примитивы, которые удаляются вместе с выделенным, помечаются как удаленные, а массивы ссылок, очищаются только после записи примитива на диск.
Всвязи с этим разрешите еще вопрос. Есть связка "стена на плане" и "оконный проем, лежащий на этой стене". При удалении проема необходимо переисовать стену.
subErase, вызванная для проема, не предполагает вызывает вызов worlDrawдля стены, удаляемый примитив при работе функции   еще не помечен как удаленный.
Придумал следующий способ, как вызывать перерисовку стены. В класс "стена" вводится дополнительное поле, которое указывает на id удаляемого с нее проема. В конце subErase открывается стена для записи, в нее прописывется этот идентификатор, и при закрытии стены, открытой для записи, она перерисовывается. Этот способ (передать id удаляемого проема, из subErase дать команду "стене" на перерисовку) мне кажется каким-то искусственным.
Вопрос: существуют ли в Oarx механизмы для разрешения таких ситуаций??? Может быть стандартно эта ситуация решается добавлением реактора к объекту "проем" или может быть еще как???
Большое спасибо, Алексеев

Re: undo в customEntity

так а просто:
acdbOpenObject(стена, стенаId,AcDb::kForWrite);
стена->recordGraphicsModified();
cтена->close()
не работает?

Re: undo в customEntity

Такой код, конечно работает, меня как-то настораживает, что он вызывается из subErase для удаляемогопроема, и я не знаю, как передать в
acdbOpenObject(стена, стенаId,AcDb::kForWrite);
стена->recordGraphicsModified();
cтена->close()
идентификатор удаляемого проема. Стена хранит id всех, расположенных на ней проемов. Удаляемый проем на момент вызова этого кода еще не помечен на удаление. Самый запсной вариант - это, повторюсь, добавить в класс <Стена> еще одно - <Удаляемый в настоящий момент проем> и перед вызовом кода для прорисовки стены, присваивать этому полю соответсвующее значение.
Такой вариант мне кажется искусственным и (например, хранить в объекте состояние, которое используется лишь в 5% от времени существования объекта), с моей точки зрения, нарушает целостность объектной модели <Стена> - <Проем>.
Суествует ли описание такой ситуации в примерах или других источниках по Oarx, если да, то как она решается родными средствами??? Было бы очень интересно узнать.
Большое спасибо, Алексеев