Re: Using same interfaces for in-proc vs. out-proc
Drew <dam@dam.com> wrote:
"Igor Tandetnik" <itandetnik@mvps.org> wrote in message
news:eGkyrl7YKHA.2160@TK2MSFTNGP02.phx.gbl...
It seems that in this case, there can only be one COM server
registered at a time
What makes you think so?
---------------
One typelib - one registered COM server.
What makes you think _that_?
and that neither is prevented from using either
of the coclasses (MyInProcServer, MyOutOfProcServer).
I don't understand what you mean by "using a coclass".
---------------
VBA:
Dim MyInproc as MyLibrary.MyInProcServer
Dim MyOutproc as MyLibrary.MyOutProcServer
Set MyInproc = new MyLibrary.MyInProcServer ' What is invoked in =
this
case, EXE or DLL?
The server whose CLSID is specified in a uuid() attribute on the =
"coclass MyInProcServer" statement.
My guess is whichever was registered last.
Your guess is incorrect.
Set MyOutproc = new MyLibrary.MyOutProcServer ' What is invoked in
this case, EXE or DLL? Same.
The server whose CLSID is specified in a uuid() attribute on the =
"coclass MyOutProcServer" statement.
The single type library in the first case, and the shared type
library in the second, would be packaged as a standalone TLB file...
-----------------
Could you elaborate on this? I've attempted this approach but end up
with shared.tlb being something like 500k and in-proc/out-of-proc.tlb
being about 3k.
Why is that surprising? They only contain the coclass and the
reference to the shared TLB.
I guess I was hoping that importlib acted like including a header.
No, it's more like linking to a DLL.
Maybe I should be using import on the shared.idl?
That would defeat the point of the exercise.
All other interfaces (including _IDualMyApp), coclasses, UDTs, enums,
etc. are in the shared.tlb. The .idl files compile fine but when I
compile my C++ code, none of them are recognized, giving 3000+
errors.
Are you using #import in your C++ code? Unfortunately, #import doesn't
automatically follow references between TLBs. You'll have to #import
"shared.tlb" explicitly.
---------------
No, I'm not using #import and would prefer not to.
Then you are #including MIDL-generated .h file. Simply #include =
"shared.h".
I bind the two
unique typelibs shown above as a resource in both EXE and DLL.
This is unrelated to compiling your source code, of course.
I assume this is where the "would be packaged as a standalone
TLB file" comes in. So how do I go about doing that?
When you compile shared.idl, a file named shared.tlb is produced.
---------------
I know this. I don't want to have to distribute this shared.tlb or
any .tlb for that matter.
Why not? You are painting yourself into a corner here.
I don't really want anything to change from
the end users perspective. They open up some VBA aware app, add a
reference to our product which is listed as it always has been and
code away.
That's how it's going to work.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not =
necessarily a good idea. It is hard to be sure where they are going to =
land, and it could be dangerous sitting under them as they fly overhead. =
-- RFC 1925