Click here to Skip to main content
15,886,199 members
Please Sign up or sign in to vote.
3.00/5 (3 votes)
See more:
Hello,

I have a project where I implement a function that sends a data over serial communication to external device. I have to wait for the response. If the response doesn't come in a reasonable time then the function returns an error, If the response is good, returns OK.

The question is, how do I make the main thread to halt and keep the events working. I can implement this by making new thread that sends the data, than waits until ManualResetEvent from the main thread resets it. But as far as I know this method involves many flags to signal which response is valid for each thread.

Is there an easy method???
Posted

Why halt the main thread? Why wait at all?

You don't want to halt the main thread: that stops the GUI completely, and the user gets fed up and gives the three finger salute.

You could move your function to a BackgroundWorker, but then when it fails (or succeeds) you need to invoke the main thread to report anything.

Instead, handle the SerialPort.DataRecieved event to catch the response, and set up a timer to allow as long as the external device is expected to take to respond.
That way, the UI still works, you can show "progress" messages to keep the user informed, and it all works the way it was meant to...
 
Share this answer
 
Comments
Sergey Alexandrovich Kryukov 22-Feb-11 15:33pm    
Nice rant, my 5.
--SA
#realJSOP 22-Feb-11 15:41pm    
Just say no to using Timers.
jfriedman 22-Feb-11 18:10pm    
greg,

It seems you are not familiar with GoF Principles. Google 'Chain of Responsibility' and 'Gang of Four'... It will greatly help you in the future to understand these principles so that you do not back yourself into these types of corners.
greg1911 23-Feb-11 1:58am    
Thanks Griff,

The thing is that I want to be sure that what I get in the port is the acknowledge for me recent message and not from my previous. So to be sure, I would like that my thread to wait for the message and not allowing the user to do anything meanwhile.

If I use what you suggest, I will have to implement a message logger for what I have sent and received.
You should never halt main thread or even do any lengthy processing in it. Also, as a rule of thumb, never use Application.DoEvents. You need to do nearly the opposite. You should run all your communications in a separate thread. Any communications with UI should be done via Control.Invoke, Control.BeginInvoke, Dispatcher.Invoke or Dispatcher.BeginInvoke.

See also: Control.Invoke() vs. Control.BeginInvoke()[^], Problem with Treeview Scanner And MD5[^] on generally used variants of using threads.

Yes, this is easy enough. Don't even play with the idea to go without multi-threading, it will be a nightmare and never got you the acceptable solution.

—SA
 
Share this answer
 
v4
Create a thread that sends the data and waits for the response. If the timeout occurs, have the thread post a custom "failure" event. If it succeeds, have it post a custom "success" event.

That way, the UI can chug along while the thread is wating for a response, and can handle the events posted by the thread when/if they're posted.
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900