Board index » cppbuilder » Client activates COM server on a thread

Client activates COM server on a thread

WinNT,CB4:  I am getting data from a National Instruments card on a thread.
When an input "event" is detected, I make a call to a server.

With CB1 I found out that I had to call CoInitialize() to get the thread
(TTHread) connected.  Then I finally figured out that I had to call
CoUninitialize() if I wanted to kill and re-spawn threads.

With my new CB4 app, I don't have to call CoInitialize().  However:  It
always throws an error on program exit.  What do I need to do?

 

Re:Client activates COM server on a thread


Hello Chris/Ranae,
You still do need to call CoInitialize() and CoUninitialize() within the
separate comm thread in order to perform COM interface calls in BCB4. Only
in the main program thread are these 2 calls done automatically for you
behind the scenes.

You might also need to look at the functions
CoMarshalInterThreadInterfaceInStream() and CoGetInterfaceAndReleaseStream()
that provide the means to marshall the COM interface from the main thread
across for use in the comm thread. Look in ole.hlp for details of these
functions.
HTH
Richard Kable
Source Communications
Melbourne, Australia

Chris & Ranae Procyk <procy...@idt.net> wrote in message
news:7ulcv1$geb18@forums.borland.com...

Quote
> WinNT,CB4:  I am getting data from a National Instruments card on a
thread.
> When an input "event" is detected, I make a call to a server.

> With CB1 I found out that I had to call CoInitialize() to get the thread
> (TTHread) connected.  Then I finally figured out that I had to call
> CoUninitialize() if I wanted to kill and re-spawn threads.

> With my new CB4 app, I don't have to call CoInitialize().  However:  It
> always throws an error on program exit.  What do I need to do?

Re:Client activates COM server on a thread


Quote
> Hello Chris/Ranae,

It's "Chris" when posting here ;>

Quote
> You still do need to call CoInitialize() and CoUninitialize() within the
> separate comm thread in order to perform COM interface calls in BCB4. Only

Bear with me: I'm a s/w consultant and as such am last in line (and still
waiting) for a 'Net connection at the site.  Hell, I don't have a real desk.
So I have to work from memory and may misspeak.  Given that warning:

I find I *don't* need to make those calls with BCB4, unlike BCB1.  They are
definitely done for me.  I put the TCOMxxxx declaration in the
TThread-derived's class declaration, and when I make that initialization
call (damn, can't remember what it is) it DOES call CoInitialize()-verified
thru de{*word*81}.  And I'm pretty sure that CoUninitialize() is also called
when that thread exits, although I had some debug stepping problems there.

It seems to me that there is a "static" instance of something or other for
some reason that is screwing me up.  It want's to undo something that's
already been done.  So many templates, so little time...

FYI: At the moment, there's no real dynamic spawning/terminating of threads.
The program starts up, reads a file specifying the parameters of the
algorithm, then spawns off this thread to actually collect and process the
data.  This thread updates the server- and the Form itself using
Synchronize()- when it sees certain events.  Eventually somebody clicks on
the "x" button and the whole thing is supposed to stop.

With BCB1, everything worked correctly when the Execute() method started out
with the CoInitialize() call, did the Variant thing with CreateOleObject(),
and made OleProcedure() calls.  Then when it saw the Terminated flag, it
called CoUninitialize().

The new code replaces all that with the new style stuff, that is, using a
vtable pointer.

Hmm, maybe the CoUninitalize() call is NOT being made after all... it seems
like I has a similar problem when I was messing with BCB1.

Quote
> You might also need to look at the functions
> CoMarshalInterThreadInterfaceInStream() and

CoGetInterfaceAndReleaseStream()

Quote
> that provide the means to marshall the COM interface from the main thread
> across for use in the comm thread. Look in ole.hlp for details of these

I'll check it out, thanks.  Of course, that means that I'll have to PRINT
your post out and take it with me... sigh, might as well rub sticks together
for heat while I'm at it...

Re:Client activates COM server on a thread


The call is made for you by TOleInit ( or some similar name - see
vcl\utilcsl.h ). But it uses the default flags ( which is apartment ).
You may want to set the threading model explicitly.

Alex

Chris & Ranae Procyk wrote:
[snip]

Re:Client activates COM server on a thread


I've been looking through utilscsl.h.... I really think the problem is that
there is a "static" TOleInit instance in one of the Create templates.  On
exit, the TOleInit method "Reset" is what throws the error, I think 'cause
the vtable is already history due to the deletion of my TThread-based class.

But I'll try the other threading models, because as I said, all these
templates are making this like "write-only" code and maybe something happens
that I just don't see.

PS:  I wanted to mess with utilscsl.h in order to help me understand what
was going on.  But copying it to my project directory didn't work, it still
was sourced out of the compiler includes.   I guess that's because it's
bracket (<xxx.h>) included.  Is there a way to make it look for it locally
first?

Alex Bakaev [TeamB] <al...@jetsuite.com> wrote in message
news:3810936C.1678637C@jetsuite.com...

Quote
> The call is made for you by TOleInit ( or some similar name - see
> vcl\utilcsl.h ). But it uses the default flags ( which is apartment ).
> You may want to set the threading model explicitly.

> Alex

> Chris & Ranae Procyk wrote:
> [snip]

Re:Client activates COM server on a thread


Change it where it is, just back it up first ;)

Alex

Chris & Ranae Procyk wrote:
[snip]

Other Threads