ActiveX Controls, event sink maps, and windows 
Author Message
 ActiveX Controls, event sink maps, and windows

I thought I knew alot about MFC's control hosting classes until now..

I was hosting a bunch of ActiveX controls on my view class.  I was doing
this by creating a CWnd object and calling CreateControl on it, saving a
list of the CWnd objects so I could iterate them.

I suddenly had need to receive events from these controls.  Like an
idiot, I set about overriding COleControlSite and CWnd to find the
default source interface and implement it on the site (then sending
notice to the "attached" CWnd, etc.).  Worked great, however I was
browsing the source on the undocumented COleControlSite and discovered
that it already finds the default source interface and routes events
through a message map like mechanism called "event sink maps".

Ok great, I tossed all my hard work and set about working with the
maps.  Still using multiple CWnd derived objects to "host" each
individual control, I found that the event sink map thing stinks!  You
must supply a control ID to each entry (forget about ON_EVENT_RANGE for
now).

Here's why that sucks:

1) Each control MUST be created with a separate CWnd derived "host".  If
you call CreateControl on a CWnd object that already has a window (i.e.
my view), the whole thing blows up.

2) The event sink map has to live in my CWnd derived class for the
"host" windows, but each "instance" of that class hosts a single control
with a single ID.

Solution #1) My view class creates every host/control with the same
control ID and the event sink map for the host window than can use one
ON_EVENT handler.

Problem #1) For every event handler my host class has, my view class
needs a handler of this type:
OnEvent1(CHostWnd* pFrom, ...) so that my view class can handle all the
events, and distinguish which control they came from.

Solution #2) The definition of the host class contains an ON_EVENT_RANGE
handler specifying all the possible IDs that the view class might assign
each control.

Problem #2) Same as #1 because my view class still needs a separate
handler, except that it will get a ID instead of a pointer.

Obviously a CDialog can host a bunch of controls and can make use of the
event sink map, so obviously I'm doing something wrong in my creation of
the controls that makes this a pain.  Can anyone point me in the right
direction?



Mon, 15 Apr 2002 03:00:00 GMT  
 ActiveX Controls, event sink maps, and windows


Fri, 19 Jun 1992 00:00:00 GMT  
 ActiveX Controls, event sink maps, and windows
It's strange how it never even occurred to me to put the event sink map
in my view class!  When looking at the CCmdTarget dispatch code (which
has an exception for CN_EVENT "messages"), It never even dawned on me
that these command messages would get routed to the parent window. doh!
Quote:

> I thought I knew alot about MFC's control hosting classes until now..

> I was hosting a bunch of ActiveX controls on my view class.  I was doing
> this by creating a CWnd object and calling CreateControl on it, saving a
> list of the CWnd objects so I could iterate them.

> I suddenly had need to receive events from these controls.  Like an
> idiot, I set about overriding COleControlSite and CWnd to find the
> default source interface and implement it on the site (then sending
> notice to the "attached" CWnd, etc.).  Worked great, however I was
> browsing the source on the undocumented COleControlSite and discovered
> that it already finds the default source interface and routes events
> through a message map like mechanism called "event sink maps".

> Ok great, I tossed all my hard work and set about working with the
> maps.  Still using multiple CWnd derived objects to "host" each
> individual control, I found that the event sink map thing stinks!  You
> must supply a control ID to each entry (forget about ON_EVENT_RANGE for
> now).

> Here's why that sucks:

> 1) Each control MUST be created with a separate CWnd derived "host".  If
> you call CreateControl on a CWnd object that already has a window (i.e.
> my view), the whole thing blows up.

> 2) The event sink map has to live in my CWnd derived class for the
> "host" windows, but each "instance" of that class hosts a single control
> with a single ID.

> Solution #1) My view class creates every host/control with the same
> control ID and the event sink map for the host window than can use one
> ON_EVENT handler.

> Problem #1) For every event handler my host class has, my view class
> needs a handler of this type:
> OnEvent1(CHostWnd* pFrom, ...) so that my view class can handle all the
> events, and distinguish which control they came from.

> Solution #2) The definition of the host class contains an ON_EVENT_RANGE
> handler specifying all the possible IDs that the view class might assign
> each control.

> Problem #2) Same as #1 because my view class still needs a separate
> handler, except that it will get a ID instead of a pointer.

> Obviously a CDialog can host a bunch of controls and can make use of the
> event sink map, so obviously I'm doing something wrong in my creation of
> the controls that makes this a pain.  Can anyone point me in the right
> direction?



Mon, 15 Apr 2002 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. ATL DLL event sink with a VB ActiveX DLL event source

2. How to Create EVENT SINK MAPS

3. Event Sink Map declaration problem

4. Event sink map

5. Event Sink Mapping

6. Implementing Event Sink for ActiveX Automation Object in global namespace

7. Event sinking is sinking me!!! :)

8. Accessing window events from an ActiveX control

9. Event Sinking on Windows 2000

10. Sinking Events with Web Browser control

11. Control Events Myth - Advise Sink vs Connection Point?

12. Sinking Fast! -- ActiveX, Splitter Window and MFC

 

 
Powered by phpBB® Forum Software