Hi all:

Using MS Visual Studio 2008 C++ for Windows 32 (XP brand), I try to construct a POP3 client managed from a modeless dialog box.

As a first step, in the  WM_INITDIALOG message in the dialog-box-procedure, I create a persistent object -say pop3- with all that Boost.asio stuff to do asynchronous connections.  Some like:

     case WM_INITDIALOG:

          return (iniPop3Dlg (hDlg, lParam));

Here we assume that iniPop3Dlg() create the pop3 heap object -say pointed out by pop3p-, and then, connect with the remote server and  initiate a session with the client’s id and password (USER and PASS commands). After that, the server is in TRANSACTION state.

Then, in response to some user input, the  dialog-box-procedure, call the appropriate function. Say:

     case IDS_TOTAL:          //  get how many emails in the server

          total (pop3p);

          return FALSE;

     case IDS_DETAIL:          // get date, sender and subject for each email in the server

          detail (pop3p);

          return FALSE;

Note that total() uses the POP3’s STAT command to get how many emails in the server, while detail() uses two commands consecutively; first STAT to get the total and then a loop with the GET command to retrieve the content of each message.

As an aside: detail() and total() share the same subroutines -the STAT handle routine-, and when finished, both leaves the session as-is.  That is,  without closing the connection; the socket remains opened an the server in TRANSACTION state.

When any option is selected by the first time, the things run as expected, obtaining the desired results. But when making the second chance, the connection hangs.

A closer inspection show that the in the second chance, the first  time that is use the statement

     socket_.get_io_service().run();

It never return.

Note that  all asynchronous wirte an read routines uses the same io_service, and the 

     socket_.get_io_service().reset();

sentence prior to any io_service.run()

Note also that all R/W operations also uses the same timer, who is reseted to cero wait afther each operation is completed:

     dTimer_.expires_from_now (boost::posix_time::seconds(0));

I suspect that the problem is in the io_service or in the timer, and the fact that  subsequent executions occurs in a different load of the routine.

As a  first approach to mi problem, I hope that someone  would bring some light in it, prior to a more detailed exposition of the -very few and simple- Asio routines involved.