Difficulties Trapping ActiveX Events

Hello Forum,

Concerning the trapping of ActiveX events...

First, let me preface this question by saying that we did find a great
deal of information in the archives.  In fact, we thought we had it.
Apparently not :(

We tested our ActiveX control in the AX Browser just to find out which
events were being generated by which actions.  We settled on testing
with the #ControlSelected: event.  This is how we set up the test:


XtremeCommandBarsPresenter>>#createSchematicWiring

(self view controlDispatch)
        when: #ControlSelected: send: #onControlSelected to: self

XtremeCommandBarsPresenter>>#onControlSelected: aControl

Sound beep.


We have the firing of events and property notifications aspects set to
true.  We also tried hanging off (self view), but that didn't work
either.  We also made sure our #createSchematicWiring method was
actually executing--it was.

What are we missing?


Cheers,

Eric

Eric,

> XtremeCommandBarsPresenter>>#createSchematicWiring
> (self view controlDispatch)
> when: #ControlSelected: send: #onControlSelected to: self

> XtremeCommandBarsPresenter>>#onControlSelected: aControl
> Sound beep.

> What are we missing?

I don't know about the ActiveX side but from the above ...

You have used the symbol #ControlSelected: (note the colon) - is that right?

Your triggered symbol and the method selector don't match
(#onControlSelected v #onControlSelected: (note the colon again)).  This
means you should have got a walkback when the event was triggered (so that
points at the above)

(minor) #createSchematicWiring should do a supersend (super
createSchematicWiring) at the start.  It probably doesn't matter here but
it's best to get in the habit.

Maybe...

 createSchematicWiring
    super createSchematicWiring.
    (self view controlDispatch)
        when: #ControlSelected
        send: #onControlSelected:
        to: self

onControlSelected: aControl
    Sound beep.

OR, as the event receiver is the same instance as the sender there is no
point in having #self as the argument (Dolphin automatically inserted it for
you)

 createSchematicWiring
    super createSchematicWiring.
    (self view controlDispatch)
        when: #ControlSelected
        send: #onControlSelected
        to: self

onControlSelected
    Sound beep

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Ian,

>You have used the symbol #ControlSelected: (note the colon) - is that
>right?

I assume it's correct.  The ActiveX Browser reveals a colon in the
symbol, and the documentation states that this event is raised with the
control that the user selected as an argument.

>Your triggered symbol and the method selector don't match
>(#onControlSelected v #onControlSelected: (note the colon again))...

I have #ControlSelected: and #onControlSelected:.  Is that incorrect?

>(minor) #createSchematicWiring should do a supersend...

I double-checked and, yes, I am supersending.

>OR, as the event receiver is the same instance as the sender there is
no
>point in having #self as the argument...

The documentation for the AX control states that the #ControlSelected:
event takes a control as its argument.  Indeed, if I leave off the
argument, the method won't even compile when I accept it.

I've gotten no walkbacks though, which tells me that the event may not
even be firing.


Cheers,

Eric

This
> means you should have got a walkback when the event was triggered (so
that
> points at the above)
>
> (minor) #createSchematicWiring should do a supersend (super
> createSchematicWiring) at the start.  It probably doesn't matter here
but no
> point in having #self as the argument (Dolphin automatically inserted
it

Eric Taylor wrote:
> The documentation for the AX control states that the #ControlSelected:
> event takes a control as its argument.  Indeed, if I leave off the
> argument, the method won't even compile when I accept it.
Does the control offer more than one EventInterface? If yes you would
have to setup another AXEventSink manually (see
AXControlSite>>connectSink) for an example. To make sure that the
AXEvent is fired you could start to trace the recieved events in
AXEventSink>>handleEvent:withArguments: . If you see the events there
the only thing I can imagine is a mismatch between the (automagically)
created event symbol Dolphin triggers and the symbol you try to catch.

Did you actually type in the Event Symbol manually? It would be worth a
try to step through the AXEventSink code and copy&paste the generated
event symbols to prevent spelling mistakes (took me hours .... :-( ).


CU,

Udo

Eric,

> I assume it's correct.  The ActiveX Browser reveals a colon in the
> symbol, and the documentation states that this event is raised with the
> control that the user selected as an argument.

Ok, I wondered about that after I posted, I wasn't sure if the
controlDispatch would pass arguments.  So, what you should have is

createSchematicWiring
    super createSchematicWiring.
    (self view controlDispatch)
        when: #ControlSelected:       "note colon"
        send: #onControlSelected:    "note colon"
        to: self

onControlSelected: aControl
    Sound beep.

> I have #ControlSelected: and #onControlSelected:.  Is that incorrect?

In your original post the #onControlSelected in the #createSchematicWiring
method didn't have a colon - probably just a typo in the post then.

> I've gotten no walkbacks though, which tells me that the event may not
> even be firing.

That would seem to be the most likely cause.  Not knowing anything about the
control, and very little about ActiveX, I don't really know what to suggest.

BTW, sorry to harp on about the colons but, from experience, it's _so_ easy
to overlook a missing one (or even an extra one) when it's part of a Symbol.

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Udo Schneider wrote:
> Did you actually type in the Event Symbol manually? It would be worth a
> try to step through the AXEventSink code and copy&paste the generated
> event symbols to prevent spelling mistakes (took me hours .... :-( ).
Or simply do a
yourAXControlSiteViewInstance sink isTracingEnabled: true.

and copy the event names from the Transcript :-)

CU,

Udo

Udo,

Thanks for your reply.

This afternoon, I'll try what you suggested.  I'm new to Smalltalk and
Dolphin, so things might go a little awkwardly.

Thanks again.

Cheers,

Eric


> -----Original Message-----
> From: Udo Schneider [mailto:[hidden email]]
> Posted At: Monday, June 12, 2006 9:01 AM
> Posted To: comp.lang.smalltalk.dolphin
> Conversation: Difficulties Trapping ActiveX Events
> Subject: Re: Difficulties Trapping ActiveX Events
>
> Eric Taylor wrote:
> > The documentation for the AX control states that the
#ControlSelected: a
> try to step through the AXEventSink code and copy&paste the generated
> event symbols to prevent spelling mistakes (took me hours .... :-( ).
>
>
> CU,
>
> Udo

Hello Eric.
Does this still fails ?

XtremeCommandBarsPresenter>>createSchematicWiring

super createSchematicWiring.

 self
    when: #ControlSelected:
    send: #onControlSelected:
    to: self

?

 From the WebBrowserShell example, it seems like the events are triggered by
the presenter itself, not by the interface.
Looking at AXControlSite>>connectSink, it seems to confirm that the
presenter is the target for the events, but can't tell for sure.

best regards
martin

"Eric Taylor" <[hidden email]> escribió en el mensaje
news:000401c68dcc$15ceb170$6500a8c0@server...

Martin,

Brilliant!  That was it.  I didn't back up far enough: I started with
controlDispatch, and then backed up to the view itself.  It never
occurred to me to step all the way back to self.  I missed that subtle
point in the WebBrowserShell sample.  But it makes sense.  The AX events
probably go all the way out to Object (or the VM) before coming back to
commandTargets (forgive my still-developing understanding of how this
works).  The first stop they would have to make on the way in is at
presenter's boundary.

Cheers,

Eric

triggered great
> > deal of information in the archives.  In fact, we thought we had it.
> > Apparently not :(
> >
> > We tested our ActiveX control in the AX Browser just to find out
which to

Hello Eric.
This is my very elemental (mis)understanding of what might be going on.
ActiveX controls comunicate events using a mechanism called connection
points. I don't know what they are, but I imagine them as some sort of
callbacks. So, when a client wants to listen to an activex control
notification, the client provides an "observer interface". Every time the
activex control wants to comunicate something, it will invoke a method in
this "observer interface".
Now, Dolphin saves us a lot of work by making events from connection points
transparent for us. Checking AXControlSite>>eventSinkClass, I suspect that
Dolphin uses an instance of AXEventSink as the observer of the activex
control.
If you check AXControlSite>>connectSink, you will see that a new instance of
AXEventSink is created using

sink := self eventSinkClass target: self presenter sourceTypeInfo: tiSink.

and somehow the activex control gets this sink as one of its observers.

So, whenever the activex control notifies something, the AXEventSink
instance receives a callback (not a clue of the details on how anything of
this happens).
Now that aAXEventSink has received the notification, it will convert it to a
smalltalk event. Again, don't know the details, but all of this seems to
happen in AXEventSink.
The AXEventSink>>handleEvent: aSymbol withArguments: anArray method contains
this line:

self target trigger: aSymbol withArguments: anArray

which I think explains why is the Presenter the one which triggers events.
When the sink instance was created (2 lines above), it was provided with
(self presenter) as a target object, and now that target object is
triggering the smalltalk event.
So I think Dolphin commands framewrok is not involved in this mechanism, and
it's even possible to change this target to any arbitrary object, not just
the presenter wrapping the activex control.

Well, this is what I think is happening with connection points, but I may be
terrible wrong.

best regards
martin

"Eric Taylor" <[hidden email]> escribió en el mensaje
news:002001c68e3d$33e235d0$6500a8c0@server...

Ian,

I'm sure that by now you've seen Martin's post.

>BTW, sorry to harp on about the colons but, from experience, it's _so_
easy >to overlook a missing one (or even an extra one) when it's part of
a
>Symbol.

That's quite all right.  I could use a good harping on this point, but
it turns out that it was just a typo in the post, not the code.  In any
case, it would seem that we have to mindful of which object we hang off
in terms of binding to ActiveX events.

Cheers,

Eric

the incorrect?
>
> In your original post the #onControlSelected in the
#createSchematicWiring
> method didn't have a colon - probably just a typo in the post then.
>
> > I've gotten no walkbacks though, which tells me that the event may
not
> > even be firing.
>
> That would seem to be the most likely cause.  Not knowing anything
about

Hello Martin,

Thank you for the detailed reply.  I think this evening I'm going to
spend some time with the AXEventSink class.  Then I'll come back to your
reply and see if I can following everything a bit better.

Thanks again.

Cheers,

Eric


> -----Original Message-----
> From: Martin Rubi [mailto:[hidden email]]
> Posted At: Monday, June 12, 2006 11:30 AM
> Posted To: comp.lang.smalltalk.dolphin
> Conversation: Difficulties Trapping ActiveX Events
> Subject: Re: Difficulties Trapping ActiveX Events
>
> Hello Eric.
> This is my very elemental (mis)understanding of what might be going
on.
> ActiveX controls comunicate events using a mechanism called connection
> points. I don't know what they are, but I imagine them as some sort of
> callbacks. So, when a client wants to listen to an activex control
> notification, the client provides an "observer interface". Every time
the
> activex control wants to comunicate something, it will invoke a method
in
> this "observer interface".
> Now, Dolphin saves us a lot of work by making events from connection
> points
> transparent for us. Checking AXControlSite>>eventSinkClass, I suspect
that
> Dolphin uses an instance of AXEventSink as the observer of the activex
> control.
> If you check AXControlSite>>connectSink, you will see that a new
instance
> of
> AXEventSink is created using
>
> sink := self eventSinkClass target: self presenter sourceTypeInfo:
tiSink.
>
> and somehow the activex control gets this sink as one of its
observers.
>
> So, whenever the activex control notifies something, the AXEventSink
> instance receives a callback (not a clue of the details on how
anything of
> this happens).
> Now that aAXEventSink has received the notification, it will convert
it to
> a
> smalltalk event. Again, don't know the details, but all of this seems
to
> happen in AXEventSink.
> The AXEventSink>>handleEvent: aSymbol withArguments: anArray method
> contains
> this line:
>
> self target trigger: aSymbol withArguments: anArray
>
> which I think explains why is the Presenter the one which triggers
events.
> When the sink instance was created (2 lines above), it was provided
with
> (self presenter) as a target object, and now that target object is
> triggering the smalltalk event.
> So I think Dolphin commands framewrok is not involved in this
mechanism,
> and
> it's even possible to change this target to any arbitrary object, not
just
> the presenter wrapping the activex control.
>
> Well, this is what I think is happening with connection points, but I
may with
> > controlDispatch, and then backed up to the view itself.  It never
> > occurred to me to step all the way back to self.  I missed that
subtle
> > point in the WebBrowserShell sample.  But it makes sense.  The AX
events
> > probably go all the way out to Object (or the VM) before coming back
to
> > commandTargets (forgive my still-developing understanding of how
this it.
> >> > Apparently not :(
> >> >
> >> > We tested our ActiveX control in the AX Browser just to find out
> > which
> >> > events were being generated by which actions.  We settled on
testing
> >> > with the #ControlSelected: event.  This is how we set up the
test: set
> > to
> >> > true.  We also tried hanging off (self view), but that didn't
work