sending msg to message loop of background thread

Well, what do you want to do? If you just want a cancel flag, then a
sync-locked flag (or possibly just a volatile field) might do the job.
With BackgroundWorke r you can detect cancel requests too. If you have
something more complex, perhaps something simple like a sync-locked
queue (checked periodically by the background thread, or woken via
Monitor.Pulse) might do the trick.

So what do you want to do?

Marc

I'm not sure exactly what you mean, but what I need to do is for the
GUI or the console app to send an message event to the worker thread's
message loop and then invoke a function on the C++ in that message
handler. I can't use a queue because I also need the same thread to
process the window messages. Unless there is a way to wait for window
messages and queue input? Maybe some sample code will make it
clearer...

static void Main(string[] args)
{
MyObject obj = new MyObject ();
obj.Start();

obj.CallSomeCpp Function(); // see below for problem with this - I
bascially need to have this be sent as a window message to the
background thread (kind of like custom messages in Win32?) so that it
goes through the window message loop and end up calling
CallSomeCppFunc tion instead of it being called directly.
}

------------------------------- MyObject definition
Start()
{
[spawns off a new thread starting at thrdStrt]
}

thrdStrt()
{
COMObject cpp = new COMObject();
cpp.StartProces sing(); // this starts the c++ object which when
processing posts events back to this thread - let's just say for
example OnUpdateStatus( ..)
Application.Run ();
}

OnUpdateStatus( ) { [do some processing] }

CallSomeCppFunc tion()
{
cpp.DoSomeOther Work(); // this will fail because all process on the
cpp object needs to be by the thread that created it.
}

Marc Gravell wrote:

Well, what do you want to do? If you just want a cancel flag, then a
sync-locked flag (or possibly just a volatile field) might do the job.
With BackgroundWorke r you can detect cancel requests too. If you have
something more complex, perhaps something simple like a sync-locked
queue (checked periodically by the background thread, or woken via
Monitor.Pulse) might do the trick.

So what do you want to do?

Marc

I'm sorry: I overlooked the C++ aspect. I was thinking pure C#, in
which case I simply wouldn't use a windows message loop for this
purpose, but simply a producer-consumer queue to manage the various
actions (only 1 shown here) on the C# side, e.g. (untested "notepad"
code):

class MyObject {
// ...
private readonly Queue<MethodInv okeractions = new (...);
public void CallSomeCppFunc tion() {
lock(actions) {
actions.Add(Act ualCallSomeCppF unction);
if(actions.Coun t==1) Monitor.Pulse(a ctions); // could be waiting
}
}
private void ActualCallSomeC ppFunction() {
// P/Invoke call to cpp.DoSomeOther Work();
}
public void Start() {
while(running) { // "Stop" condition; volatile or sync-locked
MethodInvoker action;
lock(actions) {
if(actions.Coun t==0) {
Monitor.Wait(ac tions);
continue; // re-check Stop condition, plus release pulsing
thread
}
action = actions.Dequeue ();
}
action(); // exedcute on (background) thread, but outside of
queue lock
}
}
}

Hi,

I afraid I need to have a window message loop because the C++ object is
a COM object and posts messages/events when things occur. (This object
sends messages across the network to a server then returns, and when
the real response comes back posts a messages to the window message
loop.) With the pure queue solution you have those messages won't be
processed by the background thread. Unless I'm missing something?

I have found 1 way to do this by using delegates and creating a dummy
control, but I feel that it is pretty much a hack and would like to see
if there is any other/better way. See below for modified sample code.
So this illustrates what I'm trying to achieve where the main thread
calls a function, when then triggers a window message to be send to the
second thread and gets processed through the message loop.

static void Main(string[] args)
{
MyObject obj = new MyObject ();
obj.Start();

obj.CallSomeCpp Function();
}
------------------------------- MyObject definition
Start()
{
[spawns off a new thread with STA starting at thrdStrt]

evt.WaitOne(); // wait until the new thread creates the Control before
returning
}

Control m_ctrl; // dummy control just so I can use BeginInvoke from the
main thread to post a message to the secondary one.
AutoResetEvent evt; // to ensure Control is created before it is being
used

thrdStrt()
{
this.m_ctrl = new Control(); // create dummy control on secondary
thread
this.m_ctrl.Cre ateControl();
evt.Set();

COMObject cpp = new COMObject();
cpp.StartProces sing(); // this starts the c++ object which when
processing posts events back to this thread - let's just say for
example OnUpdateStatus( ..)
Application.Run ();
}

OnUpdateStatus( ) { [do some processing] } // this gets call by the
COM/cpp object when a response is returned from the network through the
window message loop

public delegate void ProcessRequests (object sender, myparam params);

CallSomeCppFunc tion()
{
m_ctrl.BeginInv oke(new ProcessRequests (OnUserRequest) , new
object[] { this, null});
}

OnUserRequest(o bject sender, myparam params)
{
cpp.DoTheRealCp pFunction();
}

"MT" <mt*****@gmail. comwrote in message
news:11******** ************@t4 6g2000cwa.googl egroups.com...

Hi,

I afraid I need to have a window message loop because the C++ object is
a COM object and posts messages/events when things occur. (This object
sends messages across the network to a server then returns, and when
the real response comes back posts a messages to the window message
loop.) With the pure queue solution you have those messages won't be
processed by the background thread. Unless I'm missing something?

No you don't need to create a message loop for this, all you have to do is initialize your
thread to enter a STA. You do this by setting the ApartmentState to STA before you start the
thread. Initilaizing a thread for STA will force COM to create a windows and a message
queue, all you need to do is take care that you don't block the thread for instance by
calling Sleep, most other "blocking" API's in the framework are not really blocking, they
are pumping the message queue for COM messages.
Willy.

Hi Willy,

I do have my thread set to STA. When you do that you still need to call
Application.Run () to get the message loop going. Am I not using the
correct term here? Let me fill in my start function....

Start()
{
backgroudthread = new Thread(new ThreadStart(thr dStrt));
backgroudthread .SetApartmentSt ate(ApartmentSt ate.STA);
backgroudthread .Start();

evt.WaitOne();
}

I am not implementing my own message loop, I'm using the message loop
started by windows per your explanation.

My problem here is that the COM object is on this new background thread
and I don't know how to send it messages from my foreground thread
aside from using the control/delegate hack I did above. In the old
C++/MFC way I could just call Send/PostMessage, but in C# I don't see a
managed way on how to do this.

Thanks for all of your inputs. Keep them coming :)

Willy Denoyette [MVP] wrote:

"MT" <mt*****@gmail. comwrote in message
news:11******** ************@t4 6g2000cwa.googl egroups.com...

Hi,

I afraid I need to have a window message loop because the C++ object is
a COM object and posts messages/events when things occur. (This object
sends messages across the network to a server then returns, and when
the real response comes back posts a messages to the window message
loop.) With the pure queue solution you have those messages won't be
processed by the background thread. Unless I'm missing something?

No you don't need to create a message loop for this, all you have to do is initialize your
thread to enter a STA. You do this by setting the ApartmentState to STA before you start the
thread. Initilaizing a thread for STA will force COM to create a windows and a message
queue, all you need to do is take care that you don't block the thread for instance by
calling Sleep, most other "blocking" API's in the framework are not really blocking, they
are pumping the message queue for COM messages.
Willy.

"MT" <mt*****@gmail. comwrote in message
news:11******** **************@ 73g2000cwn.goog legroups.com...

Hi Willy,

I do have my thread set to STA. When you do that you still need to call
Application.Run () to get the message loop going. Am I not using the
correct term here? Let me fill in my start function....

Start()
{
backgroudthread = new Thread(new ThreadStart(thr dStrt));
backgroudthread .SetApartmentSt ate(ApartmentSt ate.STA);
backgroudthread .Start();

evt.WaitOne();
}

That's great , but I would like to see the Thread procedure, above code sys's nothing.

I am not implementing my own message loop, I'm using the message loop
started by windows per your explanation.

The COM message queue and the implicit pumping done by most of the CLR wait API's is only
ment to pump COM messages.

My problem here is that the COM object is on this new background thread
and I don't know how to send it messages from my foreground thread
aside from using the control/delegate hack I did above. In the old
C++/MFC way I could just call Send/PostMessage, but in C# I don't see a
managed way on how to do this.

If you need to send *Window* messages from the main UI thread to your "COM thread", you'l
need a form (all or not hidden)associat ed with this thread and a WndProc that handles these
messages it's up to you to implement this. The UI thread will need to PInvoke SendMessage to
send a message to the window HANDLE associated with this (hidden) form.
Another option is implement your own queue just like Marc showed you above, and forget the
whole SendMessage stuff.
But, the most appropriate option is to create the COM object on the UI thread, it was
designed for such scenario. If it happens that the COM call blocks the thread for too long a
period, well then it shouldn't have been designed as an "Apartment" threaded object.

Willy.

I see. Thank you for your explanation.

Willy Denoyette [MVP] wrote:

"MT" <mt*****@gmail. comwrote in message
news:11******** **************@ 73g2000cwn.goog legroups.com...

Hi Willy,

I do have my thread set to STA. When you do that you still need to call
Application.Run () to get the message loop going. Am I not using the
correct term here? Let me fill in my start function....

Start()
{
backgroudthread = new Thread(new ThreadStart(thr dStrt));
backgroudthread .SetApartmentSt ate(ApartmentSt ate.STA);
backgroudthread .Start();

evt.WaitOne();
}

That's great , but I would like to see the Thread procedure, above code sys's nothing.

The thread procedure was in previous posts. I've copy and pasted it
here.

thrdStrt()
{
this.m_ctrl = new Control(); // create dummy control on secondary
thread
this.m_ctrl.Cre ateControl();
evt.Set();
COMObject cpp = new COMObject();
cpp.StartProces sing(); // this starts the c++ object which when
processing posts events back to this thread - let's just say for
example OnUpdateStatus( ..)
Application.Run ();
}

>

I am not implementing my own message loop, I'm using the message loop
started by windows per your explanation.

The COM message queue and the implicit pumping done by most of the CLR wait API's is only
ment to pump COM messages.

My problem here is that the COM object is on this new background thread
and I don't know how to send it messages from my foreground thread
aside from using the control/delegate hack I did above. In the old
C++/MFC way I could just call Send/PostMessage, but in C# I don't see a
managed way on how to do this.

If you need to send *Window* messages from the main UI thread to your "COM thread", you'l
need a form (all or not hidden)associat ed with this thread and a WndProc that handles these
messages it's up to you to implement this. The UI thread will need to PInvoke SendMessage to
send a message to the window HANDLE associated with this (hidden) form.
Another option is implement your own queue just like Marc showed you above, and forget the
whole SendMessage stuff.
But, the most appropriate option is to create the COM object on the UI thread, it was
designed for such scenario. If it happens that the COM call blocks the thread for too long a
period, well then it shouldn't have been designed as an "Apartment" threaded object.

Willy.