Tied up with Threads

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.

Code:

---

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?

use a sync object

Mutex
Semaphore
etc...

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

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

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.

:confused:

Quote:

---

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.

Code:

---

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.

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