В конце работы dll остается не освобожденная память. Возможна проблема в кольцевых ссылках. Надо разобраться.
интерфейс IFont правильно, все ссылки уничтожаются.
интерфейс IBorder, IBorders, IInterior тоже правильно, все ссылки уничтожаются.
IPageSetup тоже правильно.
Исправлена кольцевая ссылка между IWorksheet и IRange.
Ошибка наблюдается в программах на FoxPro (Налогоплательщик, БухСофт).
К 0.4 не успеваю. Переношу на 0.5
модернизирована система логов, теперь легче будет отледить где происходит ошибка и какие объенкты не удаляюся... Постепенно все интерфейсы переводятся на использование макросов, чтобы избавится от возможных ошибок при приведении типов...
И так новая версия ( написанная на С++ )..не страдает этим недостатком....Закрываю ошибку, как не актуальную, для новой версии.
Аудит UniOffice от 2026-11-06. Закрытие FIXED в комментарии 8 относится к новой версии на C++, а текущая поставляемая Excel-реализация — C. Это не подтверждает устранение исходной утечки в сегодняшнем коде. В текущей реализации Workbooks хранит ссылки на книги, а Workbook_Initialize/Initialize2 удерживают Workbooks через AddRef; нормальные Close/Quit должны разрывать эту связь. Нужен целевой тест завершения: создать книгу и дочерние объекты, освободить ссылки/закрыть книгу/Quit, проверить возврат счётчика живых объектов и DllCanUnloadNow к исходному значению, включая ошибочные пути и старый FoxPro-сценарий. https://gitlab.eterfund.ru/etersoft/unioffice/-/blob/9ac6620/unioffice_excel/special_functions.c https://gitlab.eterfund.ru/etersoft/unioffice/-/blob/9ac6620/unioffice_excel/i_workbooks.c Переоткрываю для проверки текущей ветки. Отдельные современные исправления владения Range/ITypeInfo и успешные функциональные скрипты не являются исчерпывающим тестом исходной утечки. Само исходное FoxPro-приложение в этом аудите заново не запускалось; новая утечка в нём не утверждается.