Re: Animated gif
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:2m6m15hsff33pa40e4tjnc24is7c5h07d4@4ax.com...
What usually happens is the app does not come up, or a dialog fails to
launch, because the
control is missing. This isnot the same as a crash. It is not clear that
you can avoid
"DLL Hell" if you need something that is a shared product, except by using
side-by-side
installs. And if the control is private, and you are the only user, then
there is no DLL
Hell. DLL Hell is caused by inconsistent DLLs, and ActiveX/COM controls
do not
typically fall into that category because the interfaces are fixed. And
if an older
version of a control is used, that had a bug, then that is just a bug, no
more or less
likely than any other piece of bad code.
It is essentially meaningless to speak of COM as if it is a single uniform
concept. If a
specific control were under discussion, then it would be a meaningful
question. It's just
a bunch of code, and no more or less vulnerable than any other
configuration of code that
might be written. For example, the question does not distinguish between
application-specific COM controls written for the project in question,
third-party COM
controls, and Microsoft COM controls. There is no simple answer for the
generic blanket
question about "COM". It's entirely dependent on the (unspecified,
unstated, unknowable)
context. In the absence of a specific context, the question has no
meaning.
There are many possible COM interfaces to code that can show an animated
GIF. So a
"COM-based solution" is a meaningless statement. It could have been "A
DLL-based
solution" or "a statically-linked library solution" and the answer would
be the same: what
is the reliability of the librrary? The rest (static, dynamic, COM) is a
rather trivial
detail by comparison. So if the question had been "If I use the
CodeProject XXXXX
solution, which is a COM-based solution", it depends on whether or not the
code is robust
under all scenarios that would matter. The control would be installed and
registered like
any other COM control. It is likely that this application is the only
client. If there
were any concern about obsolescence/inadvertent replacement, hey, there's
this *neat*
concept called a GUID! Just specify your own GUID for the control, and
you are the sole
and exclusive owner of it. End of discussion! No possibility of DLL Hell
caused by some
other version of *that* control!
All of which says, it *should* work... neglecting to mention there is a
whole lot more to go wrong, and in fact does go wrong in the real world. In
addition to deployment complexity, consuming ActiveX controls with a raw C++
client is complex. Even with ATL's utility classes, they are plain
inconvenient to use. The problem with COM is that it forces you to think
like a compiler in order to get your C++ app to talk to this foreign "thing"
and the OS gives you very little help with the transition. What's that?
Variant args? BSTR? You don't like those? Tough! Do you need dual
interfaces? Is apartment threading good enough? What nonsense! Just to
have some animated gif code....
In fact, if the control was offered on CodeProject as an ActiveX control, I
would simply strip out the guts of it, throw out the COM wrapper, and
compile the functionality inside my app to avoid using it as an ActiveX
control, just to avoid this nonsense. ActiveX is in the same league as
STL - needlessly complex and insufficient bang for the buck. ;)
-- David