Reading the serial port usually presents problems if done in a single thread. You should
consider asynchronous I/O, or see my example of serial ports on my MVP Tips site. I have
never used WaitCommEvent simply because I have never seen any reason to wait for a comm
event. You don't need it. Generally, any unbounded wait is bad, and the serial port is
one example of a potentially unbounded wait. Don't do synchronous I/O or waits with
There are several essays on my site, and several code downloads that use multithreading,
including my async explorer, thead affinity explorer, and PowerPoint indexer.
Thanks Dan,
MSG msg;
while( ::PeekMessage( &msg, NULL, NULL, NULL, PM_NOREMOVE ) )
{
AfxPumpMessage();
}
Adding the this code above did the trick. I knew it had to be something
simple. The real program I'm working on is reading from a serial port,
processing it, and displaying, so I'm sure I'll need to study messaging
a bit further**, but this has put me in the right direction or at least
away from the wrong direction.
I'll be spending some time at Joe's site; thanks for that too.
**I just tried AfxMessagePump with the serial code and it hangs as
expected when there's no data coming in the port at:
WaitCommEvent (hPort, &dwStatus, 0);
Thanks again,
Jeff
P.S. Do you know of a short MFC app that is a good example of "best
practices"?
Dan Bloomquist wrote:
Jeffro wrote:
I'm trying to learn threads so I started a C++ MFC app in Visual
Studio 2008. It's a single dialog based app with an Edit control, a
Run button and an Exit button. The Run button sends updates to the
edit control in a continual loop. How do I get the program to respond
to events? That is, to close when I press the Exit button? Do I even
need a thread in this situation? Even if threads aren't necessary,
please show me how it would be done (with threads).
If you want to learn about threads Joe's site is highly recommended.
But you don't have to use a thread. You can use the printing loop
method. Add this:
// ................................................................
bool bGlbAbort= false;
//Returns non zerro if continue.
BOOL CALLBACK _RAAbortProc( HDC, int )
{
MSG msg;
while( ::PeekMessage( &msg, NULL, NULL, NULL, PM_NOREMOVE ) )
{
if( ! AfxPumpMessage( ) )
return FALSE;
}
return ! bGlbAbort;
}
What ever button needs to stop the loop should set a flag so that
GetIsCancel( ) returns true. I have never tried this beyond a progress
dialog with a cancel button, but I don't see why it won't work with an
app dialog. I use it while building a report object then hand it to the
dc for the printing loop. So the bGlbAbort is not necessary.
Your buttons are dead because you are blocking the message pump. So,
somewhere in your blocking code:
void CThreadPracticeDlg::OnBnClickedRun()
{
int i = 0;
while (1) {
if (i >= 10) {
i = 0;
}
if( GetIsCancel( ) )
//Post quit, return, whatever....
char intString[2];
_itoa(i,intString,10);
CString msg = CString(intString);
m_edit1.SetWindowTextW(msg);
i++;
//Not sure that this will mess catching the button press
//If you are going to be gone for extended times you may
//be better off with a second thread.
Sleep(500);
} }
void CThreadPracticeDlg::OnBnClickedExit()
{ exit(0);
}
Also, you don't need itoa and the char array.
CString strT;
strT.Format( _T("%d"), i );
Once you have used threads a few times they are not that bad. Worker
threads are very easy to use. But you will need to post a message to the
GUI thread and use a semaphore to share the data rather than alter the
window directly.
See Joe's site:
http://www.flounder.com/mvp_tips.htm
Best, Dan.
----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.pronews.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= - Total Privacy via Encryption =---
Joseph M. Newcomer [MVP]