Re: CComPtr strange behaviour
Alexander Lamaison wrote:
else if (riid == __uuidof(IExtractIconW))
{
assert(cpidl == 1);
if (cpidl == 1)
object = extract_icon_w(hwnd, apidl[0]).p;
}
The program still crashes. If I put the .p back, it doesn't!
Any more ideas?
What happens to the pointer _after_ folder_item_object returns? I bet
the caller just casts it to the expected interface type, without using
QI.
Ah, indeed:
CFolder::GetUIObjectOf(..., REFIID riid, void** ppv) {
CComPtr<IUnknown> object;
object = folder_item_object(..., riid);
*ppv = object.Detach();
}
GetUIObjectOf takes an IUnknown* pointer it got from folder_item_object,
and tells the caller that it's really a pointer of type riid (which
amounts to a downcast). Due to a happy coincidence of implementation
details, this does happen to be the case when you use ".p" form in
folder_item_object, but not when you use assignment without ".p".
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925