I'm glad you've solved it. The explanation lost me though.
On Oct 1, 4:08 pm, "Alexander Nickolov" <agnicko...@mvps.org> wrote:
With the limited code snippet you are posting I have no idea.
Most likely a message loop is irrelevant to your code. In fact,
most likely you should be using MTA instead of STA...
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnicko...@mvps.org
MVP VC FAQ:http://vcfaq.mvps.org
=====================================
"rtischer" <rtisc...@vacoxmail.com> wrote in message
news:1191258560.585943.21820@w3g2000hsg.googlegroups.com...
On Oct 1, 11:50 am, "Alexander Nickolov" <agnicko...@mvps.org> wrote:
You are leaking an interface pointer each time you unmarshal,
might that be related to your issue?
What you are doing is you are creating a new STA within each
of your methods, then you get an interface pointer and then
you close the STA thus both invalidating the interface pointer
and orphaning it. I'm surprised you don't get a crash in the
destructor of CComPtr<> since it contains garbage at this
point (e.g. after CoUninitialize)...
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnicko...@mvps.org
MVP VC FAQ:http://vcfaq.mvps.org
=====================================
"rtischer" <rtisc...@vacoxmail.com> wrote in message
news:1191252772.368091.102820@g4g2000hsf.googlegroups.com...
On Sep 30, 4:23 pm, "Alexander Nickolov" <agnicko...@mvps.org>
wrote:
The problem is in your calls to CoInitializeEx and CoUninitialize.
Lose them (move them to the beginning and end of your thread
respectively) and you should be fine.
--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnicko...@mvps.org
MVP VC FAQ:http://vcfaq.mvps.org
=====================================
"rtischer" <rtisc...@vacoxmail.com> wrote in message
news:1191018151.322761.249720@50g2000hsm.googlegroups.com...
I am getting this error when calling GetInterfaceFromGlobal in an
extension dll in my ATL server. My calling code looks like this:
HRESULT result = ::CoInitializeEx( NULL,
COINIT_APARTMENTTHREADED );
CComPtr< IMyCallback > myCallback;
HRESULT result = globalInterfaceTable-
GetInterfaceFromGlobal( gitCookie,
IID_IAtlMyCallback, ( VOID ** )&myCallback );
CoUninitialize();
I know the code is good because I can put it directly in a
spawned
worker thread and the GIT call returns S_OK. Also, since my
application code is well tested, I know the problem is not in the
thread switching or the extension dll loading or execution. This
means
that either ATL GIT marshalling has a problem with
PostThreadMessage
or extension dlls.
To test this out, I put the above code directly into the
PostThreadMessage handler and it too worked fine returning an
S_OK.
But going one step further and calling a function in the
extension
dll
from the message handler, and the code fails returning
E_NOINTERFACE.
Is there some peculiarity with marshalling that I don't know? I
am
using the STA threading model. I'm an old hand at MFC and
threads,
but
am relatively new concerning ATL's need for marshalling across
threads
in an ATL Server.- Hide quoted text -
- Show quoted text -
I moved the CoInitializeEx to the beginning and CoUninitialize to
the
end of the thread but there was no change. The first call to
GetInterfaceFromGlobal succeeds, but the second call fails. Here is
the code with the initialization surrounding each call. Both calls
occur in the switched-to thread, but the second call occurs in the
dll
code:
atlServerApp->PostThreadMessage( SOME_THREAD_HANDLER, wParam,
lParam );
...
void SomeWinAppThread::SomeThreadHandler( wParam, lParam )
{
HRESULT result = ::CoInitializeEx( NULL,
COINIT_APARTMENTTHREADED );
CComPtr< IMyCallback > myCallback;
result = globalInterfaceTable->
GetInterfaceFromGlobal( gitCookie, IID_IAtlMyCallback,
( VOID ** )&myCallback ); <-- returns S_OK
CoUninitialize();
myExtDllHandle->MyExtDllMethod(...)
}
void MyExtDll::MyExtDllMethod(...)
{
HRESULT result = ::CoInitializeEx( NULL,
COINIT_APARTMENTTHREADED );
CComPtr< IMyCallback > myCallback;
result = globalInterfaceTable->
GetInterfaceFromGlobal( gitCookie, IID_IAtlMyCallback,
( VOID ** )&myCallback ); <-- returns S_NOINTERFACE
CoUninitialize();
}
A colleague of mine suggested that the problem might be due to the
type of dll: extension dlls don't have their own message pump and
STA
marshalling depends on that (I'm still reading up on this). This
would
mean that I should switch to a regular dll which does have its own
message pump.- Hide quoted text -
- Show quoted text -
Thanks for clearing up my apartment creation problem. I understand now
that an STA apartment should only be created once when the thread is
created and that that is what CoInitializeEx does. Since the problem
still exists, we are back to the idea of message pump (regular dll)
vs. no message pump (extension dll). Could that be the problem?- Hide
quoted text -
- Show quoted text -
Problem solved.
The solution is simple and clean, but involves re-conceptualizing the
COM constructs somewhat. I apologize ahead of time for the lengthy
explanation below, but having spent this number of days finding it and
given the number of postings since 2000 that appear to involve the
same issue, I'm going to go ahead and be over wordy.
MSDN article http://support.microsoft.com/kb/q150777/ explains the
abstractions used in COM where In-proc (DLL-based) and Out-of-Process
(EXE-based) are the main application constructs. Each application
construct can use one of several threading models, the main ones being
Single-Threaded Apartment Model (STA) and Multi-threaded Apartment
Model (MTA). The mindset of this superstructure is exclusively client-
server where the COM either resides in the main process or one of its
DLLs. I would have used the Out-of-Process model, but no serious MFC
application doesn't have DLLs, and my application is no exception. My
application is MFC peer-to-peer where the architecture requires the
COM to reside in the EXE but needs access to COM callbacks from dozens
if not hundreds of DLLs. My application is therefore an "In-proc-Out-
of-Process" model, or Out-of-Process with COM-access-in-DLLs. I use
the STA model and the Global Interface Table (GIT) marshaling model
(see http://support.microsoft.com/kb/q206076/ for an explanation of
these).
We can surmise that COM doesn't like DLL boundaries, hence the need
for the In-proc and Out-of-Process constructs. The documentation also
says that COM will behave well if the rules are followed for each of
these constructs. The Out-of-Process with DLLs problem solution uses
the STA thread model with GIT marshaling rules, but I need to add the
following rule to make it work with DLLs: lookup the GIT interface
immediately after switching threads to the other apartment and then
pass the retrieved interface object as a parameter into the loaded DLL
code. This way, STA marshaling has done its job and all the DLL needs
to deal with is calling the COM interface object. Whether or not the
DLL has a message pump (regular DLLs do, but extension DLLs do not) is
irrelevant at this point. The practical steps are: implement GIT
marshaling normally which involves creating, registering and revoking
the GIT. Create on the heap a struct object with members for the GIT
cookie and globalInterfaceTable object. Pass this object into the
apartment thread as a parameter. At the apartment thread, use the
cookie and globalInterfaceTable to retrieve the interface using
GetInterfaceFromGlobal. Send this retrieved interface in as a
parameter into your DLL code via a normal DLL method call. Inside the
DLL, use the interface to call the COM method in the COM Client.