Вызов managed форм в AutoCAD

Блин, проверил в 2004 - В 2004/2005 работает все корректно... Баг ислючительно 2002-го... наверное все-таки у него с managed кодом не все срастается...

> KonstantinM
Рискну предположить, что дело в разных алгоритмах управлении памятью - 2002 акад использует механизм 6 студии, а твой код использует механизм VS.Net. Для преодоления этой проблемы я переопределяю операторы new и delete (я использую VC++7.1 вместе с 2002 акадом).

Да всё очень просто, сначала создаём dll (я назвал её crtproxy.dll), которая экспортирует всего две функции:
void* ProxyAlloc(size_t size) {
    return  (operator new)(size);
}
void ProxyDealloc(void *ptr) {
    delete ptr;
}
и компилируем это дело нужной студией (зависит от версии автокада, если 2002, то используем VC++6).
Ко всем разрабатывемым библиотека подключаем crtproxy.dll, а также добавляем файл с таким вот кодом:
extern void* ProxyAlloc(size_t);
extern void ProxyDealloc(void *);
void* operator new(size_t size) {
    return ProxyAlloc(size);
}
void operator delete(void *ptr) {
    ProxyDealloc(ptr);
}

> KonstantinM
Согласен. Но пока с этим проблем не было - не припомню ситуации, где Автокад мне возвращает простой масив, который я должен удалить, или где я создаю простой масив и отдаю его Автокаду.

Ну не знаю, подобных сообщений не видел, в какой ситуации такое наблюдается?
Вчера получили по партнёрской программе VS 2005 Beta 2, так я перекомпилировал всё тамошним комплиятором - работает нормально, никаких сбоев нет

У меня на машине (XP SP2) стоит VS 6.0, VS 2002, VS 2003 и VS 2005 Beta 2
Вроде бы всё нормально работает, но гарантировать ничего не могу - от всех этих студий я использую только компиляторы, а IDE не использую, ибо ИМХО отстой - вместо этого использую Emacs + Boost.Build.

> archimag
----------------
Да всё очень просто, сначала создаём dll (я назвал её crtproxy.dll), которая экспортирует всего две функции:
void* ProxyAlloc(size_t size) {
return (operator new)(size);
}
void ProxyDealloc(void *ptr) {
delete ptr;
}
и компилируем это дело нужной студией (зависит от версии автокада, если 2002, то используем VC++6).
Ко всем разрабатывемым библиотека подключаем crtproxy.dll, а также добавляем файл с таким вот кодом:
extern void* ProxyAlloc(size_t);
extern void ProxyDealloc(void *);
void* operator new(size_t size) {
return ProxyAlloc(size);
}
void operator delete(void *ptr) {
ProxyDealloc(ptr);
}
-------------------------
С такой жопой(сорри) столкнулся...
Чтобы экспотировать метод
void ProxyDealloc(void *ptr) в crtproxy, надо вставить __declspec(dllexport) (или еще как можно?)
Короче как только делаю __declspec(dllexport) - в 1.arx и потключаю ее к 2.dll(C++.NET) - на Managed C++ - то по закрытию акада валится эксепшен, что мол какой то эвент пытаются отправить по 0x000000...
Ты используешь crtproxy.dll только в обычных плюсовых dll-ках, или в управляемых тоже?

Вобщем могу сделать резюме, что такой "фокус" в управляемых dll-ках не проходит. Хорошо что она у меня только одна. Смог разрулить это пока только так -
1) crtproxy.dll предоставляет интерфейс IMemoryAllocator - c alloc и free
2) 2.dll - интерфейс IMemAllocatorReg и экспортирует метод extern "C" IMemAllocatorReg* GetMemAllocReg(); в 2.exp файлике экспортируется GetMemAllocReg - т.е. обходимся без  _declspec(dllexport)-а.
3) crtproxy.dll грузит 2.dll, достает через HMODULE - IMemAllocatorReg и регистрирует в 2.dll IMemoryAllocator
Такая, блин, трехходовка... :) Че еще придумать не знаю... Вообще С++.NET для того и придуман, чтоб код на С++ портировать через оболочки в .NET - но в автокаде куча сюрпризов в этом плане. То что акад по своему память выделяет - это еще пол-беды...
Ну и при такой позе приходится следить чтоб гне было глобальных переменных или статических объектов - чтоб при загрузке 2.dll - ни дай бог хотябы один объект не создался...

В Контексте программирования под автокад - это дает возможность написать на С++ свой движок с ObjectARX, а интерфейсы как оболочки (то бишь API) вытащить на .NET. А предметную область проектирования (где автокад это всего лишь вспомогательный инструмент написать на .NET) При этом код предметной области сравним или даже намного больше чем код непосредственно использующий ObjectARX. Поэтому в контексте разработки под ObjectARX это ничего не дает кроме гемора, а в контексте разработки предметного программного комплекса дает возможность юзать все прелести .NET (А писать GUI или DB на плюсах всяко геморнее чем на .NET)