External Interfacing: Best Place for Event Handling?

Hello Forum,

I've just finished creating the ExternalLibrary, including a
PoolDictionary, for a .DLL-based PDF authoring library that we use.  The
library processes four different events which, according to its
documentation, can be trapped using a callback mechanism or the Windows
messaging system.  I've decided to take the latter approach.

I've been testing the interface from Smalltalk, and so far so good.  Now
I'm going to build a friendlier interface onto this external library,
and I was just wondering where would be the best place to register an
interest in the events, the ExternalLibrary itself, or the interface
onto the library?

And just so I'm clear, from what I can gather from DSDN and Dolphin's
online help, it would seem that I need to register interest in the
events using the #when:send: family of messages.  The CreatePDF()
function in the library takes two parameters: the handle of the window
that will process the events, and message offset (the message offset
provides a way to make sure that the library's message IDs are unique
within the system).

Thanks.

Cheers,

Eric

Eric Taylor wrote:
> And just so I'm clear, from what I can gather from DSDN and Dolphin's
> online help, it would seem that I need to register interest in the
> events using the #when:send: family of messages.  The CreatePDF()
> function in the library takes two parameters: the handle of the window
> that will process the events, and message offset (the message offset
> provides a way to make sure that the library's message IDs are unique
> within the system).
#when:send:to: is definetly the way to go ... however somebody needs to
trigger these by calling #trigger. This is normally done withing a view.

So the view translates from Windows Message Dispatching to Dolphin's
#when:send:to: mechanism. So CreatePDF needs an hwnd of a View (whcich
can be obtained by "myView asParameter") processing these events.

You might want to take a look at WinAsyncSocket which is a non-visible
view to proccess IP Socket Events send by Windows. This should show you
how to register interest in specific events (by means of a Message Map).
Once your View gets these events it needs to dispatch them. This allows
to finally #trigger: the events in these dispatched methods which brings
us back to the beginning #when:send:to: ;-)

Does this make sense?

Regards,

Udo

Udo,

Thank you for your reply.

Everything you said makes sense.  But I have a question concerning
#trigger.  You said:

>#when:send:to: is definetly the way to go ... however somebody needs to
>trigger these by calling #trigger. This is normally done withing a
view.

The DLL function CreatePDF() is the one triggering the event.  It's
simply up to me to trap it.

CreatePDF() sets up the target of the event and a unique block of 4
message IDs (there are only four events to process in this library).
TrapEvent() is the function that informs the PDF engine which events are
being trapped.  The other functions in the library raise trapped events
with the appropriate message ID against the target set up in
CreatePDF().

Will Dolphin recognize the various DLL functions' raising of events as
the triggers?  I ask because it would seem like there would be no need
to use #trigger explicitly in this case.  The DLL functions would seem
to be sending this message implicitly.

BTW, what was the outcome of your research into Matisse?  It appears
from what James wrote that GemStone/S does have what you need in their
Enterprise edition.  GemStone/S _is_ impressive...and would certainly be
a more native solution.

Cheers,

Eric


> -----Original Message-----
> From: Udo Schneider [mailto:[hidden email]]
> Posted At: Thursday, June 01, 2006 5:01 PM
> Posted To: comp.lang.smalltalk.dolphin
> Conversation: External Interfacing: Best Place for Event Handling?
> Subject: Re: External Interfacing: Best Place for Event Handling?
>
> Eric Taylor wrote:
> > And just so I'm clear, from what I can gather from DSDN and
Dolphin's
> > online help, it would seem that I need to register interest in the
> > events using the #when:send: family of messages.  The CreatePDF()
> > function in the library takes two parameters: the handle of the
window
> > that will process the events, and message offset (the message offset
> > provides a way to make sure that the library's message IDs are
unique
> > within the system).
> #when:send:to: is definetly the way to go ... however somebody needs
to
> trigger these by calling #trigger. This is normally done withing a
view.
>
> So the view translates from Windows Message Dispatching to Dolphin's
> #when:send:to: mechanism. So CreatePDF needs an hwnd of a View (whcich
> can be obtained by "myView asParameter") processing these events.
>
> You might want to take a look at WinAsyncSocket which is a non-visible
> view to proccess IP Socket Events send by Windows. This should show
you
> how to register interest in specific events (by means of a Message
Map).
> Once your View gets these events it needs to dispatch them. This
allows
> to finally #trigger: the events in these dispatched methods which
brings
> us back to the beginning #when:send:to: ;-)
>
> Does this make sense?
>
> Regards,
>
> Udo