AW: [omniORB] using omniORB2 from an MFC Windows app, has anyone done this?

[Hennig Andreas]

I think, we had a similar problem. The way I interpret the (mis-) behaviour
of our system is:
Windows-threads seem to inherit properties of the creator-threads, which
apparently includes the windows event-loop and the dispatching of events
therein.  A CORBA thread does not need/use windows events, threads created
from there (and functions called from there) can therefore not implement/be
part of windows objects (or MFC).  Our way around this (interpretation ! of
the) problem is: have the CORBA thread post a special event to the
MFC-object in question (probably your CView' or CWinApp) which should then
do all the work.  In my case the function posting the event is inside the
MFC-object and looks like:

CSemaphore sema(0);
	PostMessage(hWnd,MY_SPECIAL_MESSAGE_ID,port, data);  // signal MFC
to start action
	sema.Lock(); // wait for MFC to unlock semaphore, i.e. to signal end
of action
	Sleep(100);  // safety first, give MFC chance to clean up before
accessing data	 

the semaphore is used to block the CORBA-thread until the MFC-thread
finished processing.  The MFC class therefore needs to call sema.Unlock()
when all's done.

I know, this answer is based on interpretation and a bit messy, but maybe it
helps a bit ...


Andreas