Tied up with Threads

[Albatross]

I've got a button on a dialog window which sends
off two strings over the net. But I'd like to stop
the process after the first string in order to listen
if a response has come.

void MyDlg::OnBtn1()
{
   SendString(s1);
   
// wait for an answer// 

   SendString(s2);
}
.
.
void MyDlg::OnResponseArrived()
{
//  let the OnBtn1() routine continue //
}

1. I can't put //wait for an answer// into a worker thread because
the rest of the OnBtn1() thread will continue anyway.

2. And a worker thread is out of the question because the
MyDlg object is inaccessible.

3. A CWinThread object can't work because how can it
communicate with MyDlg?
With SendMessage from a CWinThread object
MyDlg will wait for OnBtn1() to finish before reacting to
SendMessage anyway.


Any ideas?

[Mick]

use a sync object

Mutex
Semaphore
etc...

and use WaitForSingleObject(...) after you send the first string. Signal the object in OnResponseArrived(...)

[kuphryn]

One solution is to process the data individual, apart from the button handler. In other words, upon the button message handler, spawn a thread that will process the first set of data. As for the status of the button control, it is up to you to set it.

Kuphryn

[Albatross]

Mick, can you be a bit more detailed in your answer?

I've looked up the Mutex angle and it is nice to share
resources that way between threads but what
I've got is a ping pong game.

kuphryn, your are rather vague in your answer. All I read
from it is "a button spawns a thread". Nothing more.

[abc_coder]

Originally posted by Albatross
I've got a button on a dialog window which sends
off two strings over the net. But I'd like to stop
the process after the first string in order to listen
if a response has come.

void MyDlg::OnBtn1()
{
   SendString(s1);
   
// wait for an answer// 

   SendString(s2);
}
.
.
void MyDlg::OnResponseArrived()
{
//  let the OnBtn1() routine continue //
}

it´s a bad design choice to wait for something while processing an event - it blocks the event-processing queue and the app. becomes unresponsive. a better choice would be using a CThread (or a simple worker if you prefer) that would post a custom message to the dialog event queue. if btn1 is pressed, the response is to disable the button, send the first string and exit. if the data-is-here message is received, check whether the button is disabled - if it is, then send the second string re-enable the button and exit; if it isn´t, just ignore the message. In this particular case you don´t need synchronization since there´s no inter-thread data exchange and for signalling purposes just posting messages is enough.

[Albatross]

to abc_coder, that sounds very interesting. No wonder I can't dance--I am standing on my own foot.

Thanks a whole a lot