-
January 24th, 2004, 04:10 AM
#1
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?
-
January 24th, 2004, 04:15 AM
#2
use a sync object
Mutex
Semaphore
etc...
and use WaitForSingleObject(...) after you send the first string. Signal the object in OnResponseArrived(...)
-
January 24th, 2004, 12:34 PM
#3
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
-
January 24th, 2004, 01:16 PM
#4
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.
-
January 24th, 2004, 06:38 PM
#5
Re: Tied up with Threads
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.
-
January 25th, 2004, 12:49 AM
#6
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
Klatau Broada Nektau
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|