[Prev][Next][Index][Thread]

Re: COM difficulties in FD

Thanks to all for the responses.  I think my problem was due mainly to a
misunderstanding of which ID to use from OLEView.  I'll have to learn more
about what all the "stuff" it provides actually means!    The All Objects
branch provided IDs which matched the ID provided in Mr. Bertolino's reply.
Another source of my error was that I'm used to using COM from Python, which
as I'm beginning to see (I think) generates a rich and complete Python
interface based solely on the OLE type library--whose ID you pass to Python
to generate the interface.   I know just enough about Python, COM, and Dylan
to be dangerous :).  But using COM, even without knowing all the details,
has time and again (at least from Python; I'm just beginning with Dylan)
proven to be a wonderfully useful way to get real day to day work done by
moving information in and out of Office documents.   I think COM is pretty
cool.    I know even less about Corba, but it's hard to imagine that it's
any better.

Michael G. <mg01@webpickles.com> wrote in message
news:cYjy4.1181$H5.119279@typhoon1.gnilink.net...
> Pardon - I don't know too much about using the Fun'O's COM stuff, but I do
> know about COM. I would guess that create-dispatch would accept a progid
> instead of a string-guid:
>
> create-dispatch("Excel.Application")
>
> This creates an instance of the "current version" of Excel.Application
> installed on your system - this is known as a version independent progid.
> Version dependent progids have a number on the end ("Excel.Application.8"
=
> Excel 97).  See the keys in the registry under HKEY_CLASSES_ROOT for other
> progids.
>
> -Michael Garnett
>
> "Martin Bertolino" <martinb@talx.com.no.spam> wrote in message
> news:Sjhy4.31337$MD3.46719@dfw-read.news.verio.net...
> > The error is correct because you are passing in the GUID for the type
> > library (at least for Excel, I do not have Outlook 8 installed). The
CLSID
> > for Excel in my system is {00020812-0000-0000-C000-000000000046}, you
can
> > see that the GUID for the type library was generated right after the
> CLSID,
> > 12 and 13, the rest are identical.
> >
> > When using OleView, you should get the CLSID listed under the all object
> > branch.
> >
> > I'm no Dylan expert, but the "create-dispatch()" call eventually will
use
> > CoCreateInstance() with the CLSID id you pass in, and request the
> IDispatch
> > interface. The argument you are supplying is the CLSID for the type
> library
> > which is used internally by the IDispatch interface implementation to
> route
> > invokaction to the actual code.
> >
> > I hope this helps.
> >
> > Martin
> >
> > "John Whittaker" <johncwhi@earthlink.net> wrote in message
> > Yc0y4.4736$qa.212536@newsread1.prod.itd.earthlink.net">news:Yc0y4.4736$qa.212536@newsread1.prod.itd.earthlink.net...
> > > I have created a COM interface project in FD.  Whenever I call
> > > create-dispatch(...) with a CLSID after properly calling
OLE-initialize,
> I
> > > get a return value of:
> > >
> > > #x80040154.  I think this is the "class not registered" error.
> > >
> > > I have tried this with the Outlook 8.0 object library UUID and the
Excel
> 8
> > > object library UUID, as in
> > >
> > > create-dispatch("{00020813-0000-0000-C000-000000000046}" );  // Excel
> > >
> > > create-dispatch( "{00062FFF-0000-0000-C000-000000000046}" ); //
Outlook
> 8
> > >
> > > Both of these object libraries exist, as confirmed by using VC's OLE
> > Viewer
> > > tool.
> > >
> > >
> > > What am I doing wrong?
> > >
> > >
> > > Thanks for any help.
> > >
> > >
> > >
> >
> >
>
>
References: