Re: Sinking events in composite control
If I for example define IDC_MAIN_CONTAINER as 101 and replace zeros
with this define from the IDispEventImpl and sink entries.
What control should have the IDC_MAIN_CONTAINER id.
moContainerWnd should be created with this ID.
If I use
moContainerWnd.SetWindowLongPtr( GWL_ID, IDC_MAIN_CONTAINER ); in the
InitDialog the problem seems to remain.
This is surprising. I don't see any reason why it shouldn't work. Check
with Spy++ that the ID is correct.
Is moContainerWnd placed directly as a child of your dialog window, or
is there any intermediate parent. Why don't you create it with the
correct ID from the beginning, rather than setting it later?
If I don't advise the sink in the InitDialog, the same assert fails
but right after control creation.
CComCompositeControl runs AtlAdviseSinkMap during initialization (to
advise sinks) and destruction (to unadvise). It first checks whether the
sink is already advised (or unadvised), and if not, retrieves the
control using GetDlgItem and AtlAxGetControl, based on the ID in the
sink map. That's the part that fails.
When you advise manually before AtlAdviseSinkMap runs, it never gets to
GetDlgItem part, that's why you don't get the assert. But your manual
unadvise comes too late: CComCompositeControl runs AtlAdviseSinkMap to
unadvise from IOleInPlaceObject::InPlaceDeactivate, before the window is
So you have two options: either arrange your IDs so that
AtlAdviseSinkMap works (then you don't actually need to advise
manually), or override the correct spots to make sure it is never called
(or is called after the work is already done manually). Consult atlctl.h
to see what the right spots are.
With best wishes,
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