apartment for in-proc COM DLL

  • Thread starter Thread starter mobigital-ggrp
  • Start date Start date
M

mobigital-ggrp

I need to use an ActiveX control in my .netcf 1.0 sp3 application
(do not need any UI functionality of that ActiveX control)

Trying to do this by implementing a DLL with a COM
object "A" which will host ActiveX control "B".
I am calling the COM object through exported DLL functions.

I seem to be able to call the exported DLL function to
create my COM object "A" which creates control "B" from any
thread in my .netcf application, but when I call other
exported functions that actually invoke something on
Control B (through interface of COM object A), they just
hang there with sandclock spinning. However, I am able to
make these calls if done through Control.Invoke on .netcf.

Seems that Pocket PC ole.lib implementation lacks the interface
marshaling functions (i.e. those through a IStream).

Can anyone shed some light on how COM invocation
works from .netcf on Pocket PC? From a COM reference for desktop it
states that sometimes COM creates a special apartment just
for making calls into Single or Free Aprtments depending on
COM object.

* how can I determine if my OCX control is single or free threaded?
* should I make my COM object single or free threaded?
* if I can't marshal interfaces, how do I call the COM object
from background threads?
* all sources say that a DLL in .netcf is loaded when called for first
time. Does it mean that the COM will be initialized in the thread
that makes the first call to an exported DLL function?
* what is the best way to isolate the Control B from .netcf
application's
processor utilization? Looks like I am able to create my com object
with its own message loop, but the calling .netcf thread limitation
still persists. Why?

I know that CF2.0 is coming out soon, but just need to get this to
work on the current release.

any feedback is appreciated! (I am almost positive that Alex Feinman
probably has some answers ;-)

-mobigital
 
it seems that Pocket PC does not support apartment model, only supports
a free model, is that right?

On my second thought does Pocket PC support out of process COM server
instantiation?
 
I am still trying to understand why only UI thread on PPC successfully
makes calls through to the COM hosted in DLL. From most doc sources it
would seem that the thread that initially created the object will be
the main thread from which I should make calls later.

..NETCF doesn't load DLL until the first call to one of its exported
functions - so where does the COM object becomes cast with the hosting
application's UI thread? Is there something else being called by .netcf
application on its main UI thread into the DLL that makes COM remember
that thread?
 
Back
Top