COM AXEventSink connect
Locked
 
|
Maybe I'm pushing things to far here, but I was hoping someone would
be able to help me with the following. After generating a bus-load of interfaces out of the OfficeLib and OutlookLib I'm able to add buttons and menus to MS Outlook. Cool! My problem is connecting the events that you're supposed to get on clicking the menu-entry back to some event handling code in Dolphin. So (in steps): - Created a OfficeCommandBarControl by asking the containing OfficeCommandBarControls to create a button. Set the caption and visibility to true and it is now visible on the Outlook menu - Constructed an AXEventSink target: Object new sourceTypeInfo: button typeInfo. This also didn't complain. Never mind the - Then do a sink connect: button. This fails with a 16r80040200 which in the AXEventSink connect comment sais it means that the ATL based source has no such connection point. I know the target is not a real good one (should be an implementation of ICommandBarEvents), but it doesn't even get there... Stepping through the connect: code on AXEventSink shows that the OfficeCommandBarButton implements IConnectionPointContainer, but it can't find a connection point. I'm assuming this has something to do with ATL (since that's what the comment says;-) but I'm clueless as to what to do to fix it. Is this even doable or have I gone past the abilities of AXEventSink, or just misunderstanding a whole lot about event sources and sinks in COM? Marc |
|
|
"Marc Nijdam" <[hidden email]> wrote in message
news:[hidden email]... > Maybe I'm pushing things to far here, but I was hoping someone would > be able to help me with the following. > > After generating a bus-load of interfaces out of the OfficeLib and > OutlookLib I'm able to add buttons and menus to MS Outlook. Cool! My > problem is connecting the events that you're supposed to get on > clicking the menu-entry back to some event handling code in Dolphin. > > So (in steps): > > - Created a OfficeCommandBarControl by asking the containing > OfficeCommandBarControls to create a button. Set the caption and > visibility to true and it is now visible on the Outlook menu > > - Constructed an AXEventSink target: Object new sourceTypeInfo: > button typeInfo. This also didn't complain. Never mind the > > - Then do a sink connect: button. This fails with a 16r80040200 which > in the AXEventSink connect comment sais it means that the ATL based > source has no such connection point. >... It means that it doesn't have a connection point of that type. Since it seems you have passed the type info for the button's default interface (I'm assuming that is what 'button' is) then that would be the problem. You need to pass the type info for the event interface (i.e. for ICommandBarEvents). Normally this can be retrieved as the #defaultSourceInterface of the coclass (see AXControlSite>>connectSink for an example). > > I know the target is not a real good one (should be an implementation > of ICommandBarEvents), but it doesn't even get there... AXEventSink translates the incoming calls on the source interface into Smalltalk events that are triggered off the target you specify, not sent to it as messages. Therefore even if you had successfully connected, you would not have seen any calls without registering for the events. Regards Blair |
|
|
"Blair McGlashan" <[hidden email]> wrote in message news:<a7perb$mr76h$[hidden email]>...
> "Marc Nijdam" <[hidden email]> wrote in message > news:[hidden email]... > > Maybe I'm pushing things to far here, but I was hoping someone would > > be able to help me with the following. > > > > After generating a bus-load of interfaces out of the OfficeLib and > > OutlookLib I'm able to add buttons and menus to MS Outlook. Cool! My > > problem is connecting the events that you're supposed to get on > > clicking the menu-entry back to some event handling code in Dolphin. > > > > So (in steps): > > > > - Created a OfficeCommandBarControl by asking the containing > > OfficeCommandBarControls to create a button. Set the caption and > > visibility to true and it is now visible on the Outlook menu > > > > - Constructed an AXEventSink target: Object new sourceTypeInfo: > > button typeInfo. This also didn't complain. Never mind the > > > > - Then do a sink connect: button. This fails with a 16r80040200 which > > in the AXEventSink connect comment sais it means that the ATL based > > source has no such connection point. > >... > > It means that it doesn't have a connection point of that type. Since it > seems you have passed the type info for the button's default interface (I'm > assuming that is what 'button' is) then that would be the problem. You need > to pass the type info for the event interface (i.e. for ICommandBarEvents). > Normally this can be retrieved as the #defaultSourceInterface of the coclass > (see AXControlSite>>connectSink for an example). > > > > > I know the target is not a real good one (should be an implementation > > of ICommandBarEvents), but it doesn't even get there... > > AXEventSink translates the incoming calls on the source interface into > Smalltalk events that are triggered off the target you specify, not sent to > it as messages. Therefore even if you had successfully connected, you would > not have seen any calls without registering for the events. Thanks for the clarification Blair, as you may be noticing, my COM skills don't run this deep :-( I looked at AXControlSite>>connectSink and tried to evaluate: button coclassTypeInfoIfNone: [nil] and get back a libraryAndIndex not understood by TKindInterfaceAnalyzer, which is the typeInfo of the button. Looks like my typeinfo analyzer is somehow not set right. How do I fix this? Thanks so much for your help. I know this is more COM related than Smalltalk, but I'd love to get this to work! Marc |
|
|
In reply to this post by Blair McGlashan
"Blair McGlashan" <[hidden email]> wrote in message news:<a7perb$mr76h$[hidden email]>...
> "Marc Nijdam" <[hidden email]> wrote in message > news:[hidden email]... > > Maybe I'm pushing things to far here, but I was hoping someone would > > be able to help me with the following. > > > > After generating a bus-load of interfaces out of the OfficeLib and > > OutlookLib I'm able to add buttons and menus to MS Outlook. Cool! My > > problem is connecting the events that you're supposed to get on > > clicking the menu-entry back to some event handling code in Dolphin. > > > > So (in steps): > > > > - Created a OfficeCommandBarControl by asking the containing > > OfficeCommandBarControls to create a button. Set the caption and > > visibility to true and it is now visible on the Outlook menu > > > > - Constructed an AXEventSink target: Object new sourceTypeInfo: > > button typeInfo. This also didn't complain. Never mind the > > > > - Then do a sink connect: button. This fails with a 16r80040200 which > > in the AXEventSink connect comment sais it means that the ATL based > > source has no such connection point. > >... > > It means that it doesn't have a connection point of that type. Since it > seems you have passed the type info for the button's default interface (I'm > assuming that is what 'button' is) then that would be the problem. You need > to pass the type info for the event interface (i.e. for ICommandBarEvents). > Normally this can be retrieved as the #defaultSourceInterface of the coclass > (see AXControlSite>>connectSink for an example). > > > > > I know the target is not a real good one (should be an implementation > > of ICommandBarEvents), but it doesn't even get there... > > AXEventSink translates the incoming calls on the source interface into > Smalltalk events that are triggered off the target you specify, not sent to > it as messages. Therefore even if you had successfully connected, you would > not have seen any calls without registering for the events. Never mind my previous braincramp on coclass analyzers... I just used you hint above on using the event type info then your instructions in a previous message around Agents and events to tie them together. It works!!! Phew! Now to find a clean structure to tie them together... The created button actually gets returned by an add:... request, so I can't easily subclass. I couldn't find any good existing patterns in the image on how to map events back into methods. Any suggestions? Marc |
«
Return to Dolphin Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |