Re: How to late-bind Excel
- From: "maurizio" <maurizio.nardo'@polimerieuropa.com>
- Date: 7 Jun 2006 02:49:08 -0700
1) Delphi can use Excel as a server with early binding (binding Excel's
type library),
but this adds about 350 kb to its code: i don't like it.
2) My DLL is, mostly, a library of functions that are called from VBA.
However, having
the right reference, the DLL can interact with and/or transfer data to
Excel directly.
Further, it would be nice to move part of the code from VBA to the DLL
(maybe
not faster, but at least to protect the code).
3) For Delphi, the reference to Excel is simply a variant (to be
precise an OleVariant,
i.e. a variant compatible with ole types). You create it, for example,
with the usual
xlapp := GetObject ('Excel.Application');
(well, in Delphi the method is called GetActiveOleObject )
4) Delphi knows how to treat xlapp as a IDispatch interface, so it
accepts a
statement like
xlapp.Caption := 'My application';
which is identical to a vba statement.
The whole point was only related to the inconvenience of the GetObject
method:
assuming we have multiple copies of Excel running at the same time, how
do you make yourself sure that you're are linking your dll to the RIGHT
instance ?
My idea was to pass to the dll (in an initialization step) the object
Excel.Application:
after all this should be passed somehow as an address, from which it
should be
possible to recover the right value to initialize the xlapp variable in
Delphi.
Hope this makes a little bit more clear the original post and its
purpose.
.
- Follow-Ups:
- Re: How to late-bind Excel
- From: NickHK
- Re: How to late-bind Excel
- References:
- How to late-bind Excel
- From: maurizio
- Re: How to late-bind Excel
- From: NickHK
- How to late-bind Excel
- Prev by Date: RTD feeds into excel not trigering a worksheet change macro
- Next by Date: Print 2 pages per sheet
- Previous by thread: Re: How to late-bind Excel
- Next by thread: Re: How to late-bind Excel
- Index(es):
Relevant Pages
|