Another "Can Smalltalk do this?" question.

Dolphin and Windows experts,

I need to write a plug-in for Adobe Acrobat.  These are generally DLLs
written in C and placed in a directory so that Acrobat can find and load
them when Acrobat starts up.  This will be a fairly complicated plug-in
that requires some experimentation and trial and error.  Using C, the
standard cycle would be edit, compile, start Acrobat, set breakpoint,
invoke plug-in, debug, stop Acrobat, and start over hundreds of times.  
This is too complex and I'm looking for a way to streamline it.

I know that I can't get a DLL out of Dolphin 4 (and even if it was
possible, having to package the DLL each time would be a burden during
development), but I can probably write some glue code in the DLL that
might be able to communicate with Dolphin.  What is the best way to do
this?  I originally thought that some interprocess communication would
be the way to go, but then there is probably a problem with address
spaces.  Acrobat passes a set of pointers for its functions so that the
DLL can call them.  A separate Dolphin process would not be able to use
them.  Is it possible to use Dolphin as an (I'm really uncertain of the
terminology here) in-process COM-server to allow it to call the Adobe
functions via a pointer?  Is that what I need or does anyone have a
better suggestion?

Thanks very much.

Keith Alcock

Keith

You wrote in message news:[hidden email]...
One of COM's capabilities is the ability to call across processes. In order
to do this you will need to create a DLL which implements the Acrobat plugin
API, and converts it to COM calls to the actual server implemented in
Dolphin. The stub should define a COM interface that incorporates all the
functions (or you may find that an OO implementation can be simpler), let's
call this the outbound interface. You may also need an inbound interface for
Dolphin to call back.You should define any interfaces in IDL and compile it
with MIDL into a type-library and proxy-stub code. The proxy-stub code is
needed to marshalling the cross-process calls, unless you are able to make
the interface(s) automation compatible. The proxy-stub code can be linked
with the stub DLL. Then you can auto-generate a wrapper (or wrappers) for
the interface(s), and implement the outbound interface on a COM server
object in Dolphin.

It sounds more complex than it is really - there are just a lot of separate
things that need to be done. It can certainly be done though, as we have
implemented similar things in the past.

>...  Is it possible to use Dolphin as an (I'm really uncertain of the
> terminology here) in-process COM-server to allow it to call the Adobe
> functions via a pointer?  Is that what I need or does anyone have a
> better suggestion?

It is possible to do an in-process COM server with Dolphin. The Netscape
plugin is an example of such. However the capability was not generalised in
4.0, and not accessible to you as Dolphin user. In the forthcoming Dolphin
5.0 it is possible for a Dolphin user to build in-process (DLL) COM servers.
The code of the actual COM server implementation in Dolphin is exactly the
same in the in-proc or out-of-process case, and you would still need the
intermediate 'stub' DLL (since Dolphin 5.0 can only implement COM DLLs, not
DLLs containing static functions). In summary, the amount of work would be
about the same, though the result will be somewhat neater since Dolphin will
run up inside the Acrobat process rather than as a separate process (and
yes, it is possible to run up the development image in-process when
developing/debugging an in-process COM server).

Regards

Blair