Re: Internationalization
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:tscfn39v86jdmqjfv48cdsdlukoopv76qj@4ax.com...
That's yet a different issue. I've avoided, except in one case, being an
automation
server. But I've written several programs that use automation, and the
choice of MFC vs.
ActiveX is not one the programmer necessarily has control over. For
example, one program
I delivered used a graphics support package, which only had an ActiveX
interface, which we
had to use. OleDB database interface is clearly an OLE interface. I've
used a
communications library that only exported ActiveX interfaces. About one
in five of my
projects requires that I talk to an ActiveX interface of some third-party
vendor
preselected by my clients. So my preference doesn't enter the picture; if
I'm using the
embedded-system-download-interface for brand X embedded processor boards,
then I have to
use the brand X ActiveX control to interface to it. If I'm using the
Brand Y grid
control, it's ActiveX. The brand Z graphics package, ActiveX. And so on.
Yes, but the confusion is merely consuming ActiveX controls does not mean
OLE automation. It does mean OLE, but not OLE automation. I have not heard
of redistributing OLE DLL's for quite some time and am not sure whether the
customer needs to get them from Wndows Update or if you really can
redistribute them. I used OLE to control Internet Explorer through it's
interfaces and did not redistribute any OLE DLL to enable that.
While I don't
create these controls (I prefer to use MFC controls when I have to create
them), I don't
have a choice, because the customer has chosen the product and I am to
build an
application that interfaces to it. And there have been bugs in the
ActiveX support DLLs
which generated support calls; I have a colleague who is an ActiveX guru,
so when I see
certain problems, I sometimes send him email, and get responses of the
form "That problem
was true of the version n.m release of <name of OLE DLL here>, and was
fixed in later
versions". We go back to the customer, and indeed, they have that version
installed. We
tell them to install the appropriate updates, and the problem goes away.
This was
certainly true in Win2K, but I've not seen or heard of it in XP.
Anyway, the point is that statically linked MFC apps can indeed get away
without redistributing any DLL's. And it's not special casing 2 of the
DLL's either.
-- David