Type libraries

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Type libraries

Bill Schwab
Hi Blair,

I have a long-standing COM server that needs to be updated for D5.  An ugly
chicken and egg problem goes away if I change the GUIDs; then the old
version can continue to work while I'm fiddling with the new stuff.  After
realizing that, it seemed wise to update it for self-registration of the
server, and probably to go to Automation compatible interfaces and therefore
obsolete the marshaling DLL.

One question: am I correct in remembering that you've mentioned problems
with getting type libraries to self-register?  If so, what's the solution?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Type libraries

Bill Schwab
Hi Blair,

Deciding to just give it a try, I wrote IDL for the Automation compatible
component, ran MIDL, generated a wrapper, dragged the protocol, etc. and got
it going, at least up to testing in the development image.  Things got
interesting (or was it boring?<g>) when I tried to deploy the server: Lagoon
seemed to stall out after displaying the "Please wait while Lagoon
terminates" message.  I tried it a few times just in case it was a fluke,
and finally let it run (on a P4-1.8GHz) for several minutes with the same
results.

Remembering a slightly different problem I had with a vtable interface in
the past, I added a manual dependency on the Automation package, and all was
well.  The previous problem (a DLL deployment) gave me a "working" DLL that
generated errors when I tried to invoke any of its methods; retaining the
Automation package fixed that problem.  This time, the deployment just
stalled out.  I don't know whether the problem is due to a change in the
release version of Lagoon, the EXE vs. DLL stripper, or just something about
the code.  The EXE is an updated version of a simple but very real COM
server; the DLL was a throw-away test.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Type libraries

Blair McGlashan
In reply to this post by Bill Schwab
"Bill Schwab" <[hidden email]> wrote in message
news:acpajm$apq$[hidden email]...
> Hi Blair,
>
> I have a long-standing COM server that needs to be updated for D5.  An
ugly
> chicken and egg problem goes away if I change the GUIDs; then the old
> version can continue to work while I'm fiddling with the new stuff.  After
> realizing that, it seemed wise to update it for self-registration of the
> server, and probably to go to Automation compatible interfaces and
therefore
> obsolete the marshaling DLL.
>
> One question: am I correct in remembering that you've mentioned problems
> with getting type libraries to self-register?  If so, what's the solution?

TLBs built into a DLL deployed by Dolphin (on NT only, since Dolphin does
not support resource updating on Win9X due to missing Win32 APIs) will be
registered when the DLL is registered with regsvr32.exe (or other utility).
Otherwise you can cause the type library to be registered by loading it up
with Dolphin's Active-X Component Wizard. If it is already registered then
it will appear in the list of available type libraries, otherwise you can
browse for the file and it will be implicitly registered when you OK back to
the loaded libraries list.

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

Re: Type libraries

Bill Schwab-2
Blair,

> TLBs built into a DLL deployed by Dolphin (on NT only, since Dolphin does
> not support resource updating on Win9X due to missing Win32 APIs) will be
> registered when the DLL is registered with regsvr32.exe (or other
utility).

That explains a little.  Just out of curiosity, would DLL deployment
otherwise work on 9x?


> Otherwise you can cause the type library to be registered by loading it up
> with Dolphin's Active-X Component Wizard. If it is already registered then
> it will appear in the list of available type libraries, otherwise you can
> browse for the file and it will be implicitly registered when you OK back
to
> the loaded libraries list.

The server is an EXE, and I'm concerned about deployment.  It looks like
I've managed to hack together a solution: when the app sees /REGSERVER, it
makes a best-effort attempt to load/register the type library from system32,
sends #register to the COMInterfaceImp subclass of interest, and then exits.
I tried letting Wise self-register the type library without success.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]