> What are the least requirements so that a COM component I design will be
recognized
> by the ActiveX wizard in Dolphin XP?
Look in Ian's archives for a December 2001 post of Blair's including a
recipe/pattern for building COM objects in Dolphin. That should get you
started. Dolphin's COM mapping is extremely well designed, so the learning
curve is not as bad as it might first appear. Get a copy of Rogerson's
"Inside COM".
<IMHO>
With the above said, have you thought about why you want a COM object? If
it is simply to modularize your Dolphin app, I recommend NOT doing it. You
would be much better served spending you time on making extensive unit tests
such that you can test and deploy with confidence. Modules are all well and
good, but with them comes interfaces, which not only put a daunting break on
change, but also greatly complicate your work.
Remember that as a skilled Smalltalk programmer (now or in your forseeable
future), you can accomplish the work of a small team of C* programmers,
which in turn can arguably do more than a large team of C* programmers<g>;
it is very unlikely that you would benefit from modules for their own sake,
and quite likely that you would suffer because of them.
If you need COM for an extension to some off the shelf product, then have at
it. Otherwise, you should think hard before starting. I'm down to one COM
server, and it is on borrowed time, mostly because sockets are a more
generic IPC mechanism, are readily available on other operating systems
(sorry, but I'm always planning on being in business not only next week, but
five years from now), and are ultimately less trouble to handle than COM
IDL, MIDL, type libraries, interface/component registration, etc. If your
requirements can be re-stated in terms of a generic IPC mechanism, use
sockets.
</IMHO>
Have a good one,
Bill
--
Wilhelm K. Schwab, Ph.D.
[hidden email]
Locked
