[WinnyThePooh]

Формирую отчет в Excel (в частности, 2000) через OLE-объект. По завершении формирования есть желание отключится от него и от сформированного файла (типа, пусть дальше сам(и) живе(у)т).
Пытаюсь так:

Код:

//Переменная
var
  XLApp: OLEVariant;
//Запускаем Excel
  XLApp:=CreateOleObject('Excel.Application');
//далее - работа
...
//в конце
  XLApp:=UnAssigned;

Ан нет! Пока не закрыта "порождающая" программа, Excel закрывается с ошибками, в памяти остаются болтаться процессы и т.п.
Попытка использовать XLApp.Free выдает ошибку, типа "этот метод низ-з-зя использовать с переменной типа Variant".
Имеется ли принципиальная возможность отцепится от порождающего процесса или проще описать как фичу в документации или посоветуйте - как быть?

[Aristarh Dark]

Попробуй сделать:

Код:

XLApp:=Disconnect;
//а потом уже
XLApp:=UnAssigned;

[WinnyThePooh]

Насколько я понимаю, Disconnect - метод при работе с COM-серверами, здесь же - OLE-объект.
По крайней мере предложенную Вами форму система не воспринимает.

[Aristarh Dark]

Это потому что я фигню написал, нужно:

Код:

XLApp.Disconnect;

[WinnyThePooh]

Не беспокойтесь, я и так сообразил
Но увы, как я Вам и писал в прежнем ответе: disconnect - метод COM-серверов.
При попытке слепить его к ссылке на объект OLE Automation (а именно его я пытаюсь применить) система выдает:
"Project ... raised exception class EOLEError with message 'Method 'disconnect' not supported by automation obect'". Т.е. метод явно не тот.
Увы, но и COM-серверами мне пока не удалось достичь успеха: пока не загасишь вызывающее приложение, Excel вываливается с ошибкой: "Инструкция по адресу 0х... обратилась к памяти по адресу 0х... Память не может быть 'read'". Причем адреса одинаковы - явно что-то слетает в указателях.
В общем, ж...
Кстати, в доступной литературе как-то тоже описываются случаи принудительного гашения OLE-объектов при закрытии приложений и нигде особо не описывается "отпускание в свободное плавание". Может это таки фича OLE'й и я зря пытаюсь её "исправить"?

[san-46]

Ан нет! Пока не закрыта "порождающая" программа, Excel закрывается с ошибками, в памяти остаются болтаться процессы и т.п.

Утверждение, не соответствующее действительности. "Порождающая" программа при использовании позднего связывания (как здесь: CreateOleObject) не "держит" COM сервер и никакого влияния после окончания работы на него не оказывает. Поэтому "отключения" от сервера не требуется. Если работа завершилась корректно, то "породившая" процесс программа может спокойно завершаться - Excel (если та же программа его не пристрелила) остается загруженным как отдельное приложение никак не связанное с вызвавшем приложением.

Процессы (Excel) остаются в памяти тогда (и только тогда), если во время вызова методов COM сервера Excel ПРОИСХОДИТ ошибка (неверные типы параметров, не в том месте вызван метод и т.д.; видов ошибок может быть тьма), а на момент ошибки интерфейс Excel скрыт и нет возможности корректно закрыть окно Excel'я.
Специально для таких случаев завершение работы с Excel в блоке except надо применять метод сервера Quit (к примеру, XLApp.Quit)

Если после экспорта из "порождающей" программы при "ручном" закрытии Excel происходит ошибка, то это глюки системы, поскольку (как было выше отмечено) клиентское приложение после окончания работы с COM сервером (корректно или с ошибкой) никак не может на него влиять. Правда, такое может произойти и тогда, когда приложение сделало какое-то количество ошибок при обращении к неверному диапазону ячеек в параметрах методов при экспорте данных.
Присвоение в конце работы вариантной переменной Unаssigned, которая ссылается на COM сервер, необходимо.