Требуется ли вызывающему объекту освободить IShellBrowser*, полученный с помощью недокументированного сообщения WM_GETISHELLBROWSER (WM_USER+7)?

StackOverflow https://stackoverflow.com/questions/1909853

  •  19-09-2019
  •  | 
  •  

Вопрос

Некоторые отметили, что существует недокументированное сообщение, которое извлекает указатель интерфейса IShellBrowser из общего диалогового окна HWND для диалоговых окон открытия и сохранения файла.

Но существует противоречивая информация (или нет информации) о том, является ли этот указатель AddRef, или это просто возвращаемый необработанный адрес, и для него не следует вызывать Release()?

Это было полезно?

Решение

Нет.Возможно, вам будет полезна следующая ссылка: Правила компонентной объектной модели .

Отрывок:

Правила подсчета ссылок

Правило 1:AddRef должен быть вызван для каждой новой копии указателя интерфейса, а выпуск требует каждого уничтожения указателя интерфейса, за исключением случаев, когда последующие правила явно разрешают иное.

Следующие правила вызывают общие невыполнения правила 1.

  • Правило 1а:Входные-выходные параметры в функции.Вызывающий объект должен AddRef к фактическому параметру, поскольку он будет освобожден вызываемым объектом, когда выходное значение будет сохранено поверх него.
  • Правило 1б:Получение глобальной переменной.Локальная копия указателя интерфейса, полученная из существующей копии указателя в глобальной переменной, должна подвергаться независимому подсчету ссылок, поскольку вызываемые функции могут уничтожить копию в глобальной переменной, пока локальная копия еще жива.
  • Правило 1с:Новые указатели синтезировали из «тонкого воздуха». Функция, которая синтезирует указатель интерфейса, используя специальные внутренние знания, а не получая его из какого -то другого источника, должна выполнять начальный добавок на недавно синтезированном указателе.Важными примерами таких процедур являются процедуры создания экземпляров, реализации IUnknown::QueryInterface и т. д.
  • Правило 1г:Возврат копии внутренне сохраненного указателя.После того, как указатель был возвращен, вызываемый абонент понятия не имеет, как его время жизни связано со временем жизни внутренней копии указателя.Таким образом, вызываемый объект должен вызвать AddRef для копии указателя перед его возвратом.

Правило 2:Особые знания со стороны куска кода отношений начала и окончания жизни двух или более копий графического указателя могут позволить пары добавления/выпуска быть пропущенными.

  • С точки зрения COM-клиента подсчет ссылок всегда относится к концепции каждого интерфейса.Клиенты никогда не должны предполагать, что объект использует один и тот же счетчик ссылок для всех интерфейсов.
  • На возвращаемые значения AddRef и Release не следует полагаться, их следует использовать только в целях отладки.
  • Стабильность указателя;Подробности см. в файле справки OLE в разделе «Правила подсчета ссылок», подраздел «Стабилизация указателя this и поддержание его достоверности».

См. Превосходную техническую статью «Управление целями жизни в Оле» Дугласа Ходжеса и глава 3 Inside Ole, 2-е издание, Крайг Брокшмидт (библиотека MSDN, книги) для получения дополнительной информации о подсчета ссылок.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top