Сообщения AutoCAD: "ENTERNAL ERROR: !U:\... dbobji.cpp@5619:eNotOpenForWrite" и "Error handler re-entered. Exiting now." (Страница 1 из 4)

Если это происходит после первого успешного использования какой либо команды, то скорее всего в ней происходит открытие AcDb... для чтения или записи, но после не предусмотрено закрытие ->close(). Повторное открытие базы, на мой взгляд, может породить подобные ошибки.

Думаю, что не достаточно тщательно ведётся контроль ошибок. Какой-то вызов прошёл неудачно, что не было вовремя обнаружено. По крайней мере, у меня подобные ошибки часто наблюдались до тех пор, пока я всерьёз не обеспокоился проверкой ошибок. Однозначно, после каждого вызова функции из Arx должен проверяться код ошибки, иначе приложение всегда будет работать нестабильно.

Почему Autodesk не выпустил хотя бы перечень сообщений с их интерпретацией, я уже не говорю об специальном отладчике?
-pure virtual function call
помойму тут все понятно. Если вылетает такое сообщение это значит что зовется из виртуальной таблицы метод, тело которого отсутствует.
Теперь по порядку чтоб стало ясно.
У тебя есть твои объекты? Т.е. custom objects?
Наверняка есть... раз летит такое сообщение.
Замени все assertReadEnabled(), assertWriteEnabled(), на assertReadEnabledMy() и assertWriteEnabledMy - поставь там try catch вокруг вызова соотвествующих assert...Enabled(). Теперь пользуй дебаг и call stack.
И еще, юзаешь ли ты чисто виртуальные метода?  интерфейсы?
Короче баг стопудово твой.
вот.

Думаю, что так оно и есть ... у меня было подобное поведение Автокада. Забывал вызывать close() для AcDbDictionary* и как только исправил - всё стало нормально. А, вот ёщё, после получал итератор (AcDbDictionaryIterator*) и забывал вызывать для него delete pIter; Видимо потому, что newIterator() никак не вызывал у меня ассоциацию с оператором new после вызовакоторого надо использовать delete. Ну а аналогичного ->close() для pIter не нашёл и успокоился ... а зря.

Лучше постарайся переложить этот труд на компилятор и используй интелектуальные указатели smartPointers<>
Окупаемость усилий фантастическая - о подобных багах думать перестанеш, если сделаеш по уму конечно

Сообщение о выове чисто виртуальной функции может лететь по трем случаям (как минимум).
1) Есть две завязанных dll - одну пересобрал, одну нет - получается что одна dll может дергать какое-нибудь гавно из другой.
2) Баг С++ компилятора.
Допустим есть интерфейс:
interface ISample
{
   void testFunc(MyType) = 0;
}
при этом в From1dll.h
#include "ISample.h"
#include "MyType.h"
class SampleSingleton : public ISample
{
void testFunc(MyType myType)
{
...
}
}
в From2dll.cpp
№include "ISample.h"
#include "MyType.h"
ISample* pSample = getSampleSingleton();
pSample->testFunc(myType);
Ну дак вот получается что компайлер и линкер все это прохавывает. Но есть в С++ такая особенность что если тип не указан, то переменная считается типом int. Вот и получается что ISample - компиляется с функцией которая принимает переменную int MyType - после этого при создании класса появляется метод уже с переменной MyType myType - все это компиляеца и компайлер не выдает баг что пытаетесь проинстанциировать абстрактный объект. При этом в виртуальной таблице есть абстрактный метод - который никуда ни указывает (чисто абстрактный). При попытке вызвать этот метод - появляется вышеследующее сообщение
-pure virtual function call
3) Третья причина - самая распространенная - это грязная кастовка указателей - с последующим дерганием методов и созерцанием оного сообщения.
4) По третьей причине может происходить такая ситуация. Указатель на что-то указывает в "жопу" (сорри, т.е. не инициализирован). Вы пытаетесь сделать что-то чтоб этот указатель присвоить (типа открыть объект и установить объект). Но !вдруг! объект не открывается - вы делаете return из метода и указатель продолжает указывать в "жопу". Далее этот указатель кастуется к чему то и у него дергаются метода... получается опять же знакомая картина.
Причем баг по причине 4) очень свойственен нутрям автокада. Т.е. стоит только что-то забыть закрыть - акад может вылететь N-различными способами.
Один из самых показательных примеров. Выделяем в акаде >2 объектов. Программно через erase() один объект убиваем. Далее пытаемся в акаде сдвинуть оставшиеся объекты... акад вылетает сразу и молча - даже не успевает оставить предсмерный assert/exception или табличку с предложением отправить информацию об ошибке - на деревню дедушке, не делает аварийные логи, не пытается аварийно записать файлики - короче смерть мгновенна и фатальна.

> Сергей
>Если я не ошибаюсь - smartPointers<> из раздела COM программирования
Вы ошибаетесь. Интелектуальные указатели одна из стандартных и широко используемых идиом С++. В том числе, они широко используют при программировании СОМ. Лично я не представляю, как можно программировать arx-приложения и не использовать интелектуальные указатели: отслеживания правильности вызововов close будет занимать все основные силы. Широкое использование интелектуальных указателей не требует каких-либо дополнительных усилий, но одним махом снимает проблему close.

> archimag
"Лично я не представляю, как можно программировать arx-приложения и не использовать интелектуальные указатели"
Легко и непринуждённо, вопрос дисциплины: открыл закрыл, зато понятно когда AcDb...* , будет прибит. Смарт указатели это конечно удобно, но за удобство приходиться платить, как всегда. Кстати, а как насчёт отладки? Она столь же проста и удобна как "умные" указатели?

> archimag
Абсолютно согласен
Чтобы долго не спорить мини-пример:

template<typename T>
class MySmartPrt
{
public:
    MySmartPrt() : object_(NULL) {}
    ~MySmartPrt()    {  close();    }
    Acad::ErrorStatus open(AcDbObjectId id, AcDb::OpenMode mode)
    {
        close();
        object_=0;
        return acdbOpenObject(object_, id, mode);
    }
    void close()
    {    
        if(object_){    object_->close(); object_=0;    }
    }
    T* operator->()        {    return object_;    }
    const T* operator->()const    {    return object_;    }    
private:
   T* object_;
};
//Теперь используем - Вариант1
void someFunc1(AcDbObjectId id)
{
    MySmartPrt<AcDbLine> line;
    if(line.open(id, AcDb::kForWrite)!=Acad::eOk) return;
    line->setStartPoint(...);
    line->setColorIndex(...);
    line.close();//закрываем принудительно
}
//Теперь используем - Вариант2
void someFunc2(AcDbObjectId id)
{
    MySmartPrt<AcDbLine> line;
    if(line.open(id, AcDb::kForWrite)!=Acad::eOk) return;
    /*some new logic
    */
    return;[b]//вот тут вся красота!!! Если использовать стандартный способ линия останется открытой
           //В нашем же случае всю работу сделает деструктор MySmartPrt[/b]
    line->setStartPoint(...);
    line->setColorIndex(...);
    line.close();[b]//закрываем принудительно
                //Наличие указателя не мешает мне принудительно закрывать объект[/b]
}

Кстати в ObjectArx есть готовая реализация "умного" указателя. Это шаблон, называется AcDbObjectPointer и лежит в
dbobjptr.h.

Я использовал класс-наследник AcDbObjectPointer, который кидается исключениями в случае возникновения ошибок типа некорректного открытия объекта. При работе с таким классом, смарт-указатель всегда должен находиться внутри try-catch секции, которая очень хорошо ограничивает область видимости указателя. Так что (за редким исключением) объект остается открытым ровно столько, сколько это необходимо.

> Сергей
>При работе с базой данных Autodesk
>рекомендует как можно скорее закрывать базу
Да кто-же спорит. Ну поставь, просто, в нужном месте пару фигурных скобок, ограничивающих область видимости, и всё! Это же элементарно...
>Эффективным применением обобщённого >программирования в системе с ...тилетним >наследием не разбалуешься.
Вы не любите кошек? Вы просто не умеете их готовить!!! Ещё как разболуешься! Я занимаюсь этим последний год и очень доволен результатом. Обобщённое программирование рулит даже применительно к такому диназавру как ObjectArx (кстати, вы не замечали, что Autodesk тоже его использует?).
>Г-н Джон Роббинс...
Да бог с ним, с этим господином (никогда о нём не слышал), весь мир уже понял, что исключения весьма эффективный инструмент, значительно облегчающий такое нелёгкое дело, как обработка ошибок и значительно повышающий надёжность программ (естественно, при грамотном использовании). Я уже как то говорил, что комбинация интелектуальных указателей и исключений, применительно к ObjectArx, способна по крайней мере вдвое сократить размер код и многократно повысить его надёжность. Проверено на собственном опыте.