On Fri, 2002-08-30 at 04:44, Marck D Pearlstone wrote: > > > .. then something may occur to terminate the connection > > prematurely, > > I think this is what is happening...
It would certainly make sense ;) We just have to establish a) why it is terminating prematurely, b) how to stop it, and c) how to reset that socket/variable when it does happen. > > then that global variable (probably a boolean) is not reset to the > > state reporting that it is not doing anything. > > I think that the client side Socket connection is left open and > until it is flagged as closed TB won't open a new one. Then just swap some of my words around, and you have the same theory as that. Except it appears in 1.6x it displays a message saying you cannot close TB! because the connection is still active. The only reason I have a slight suspicion it is not a socket is because you can always free a socket (socketname.free will release the resources in Delphi), but it may be worth seeing if RitLabs would be willing to release a special version to those having trouble with a hidden menu, which resets the socket, or the global, or however they are checking to see if there is an 'active connection'. > > Maybe if somebody that has regular contact with the developers > > (Marck? Allie?) pose the above theory, > > It may be worth a BugTraq entry. It never happens to me (Win2k Pro, > LAN connect to MDaemon server, polling for mail every 1 minute > (that's right - sixty seconds!). I think it requires a POP server on > the other end that is capable of losing the connection. MDaemon > doesn't appear to be <g>. I cannot get it to happen to mine either, and I'm in arms reach of one of my mail servers (litterally I spin around on my chair, and I can touch it), this machine is another one, and my 3rd one is back home in the UK. > > Try seeing if you can terminate the connection in an abnormal way, > > such as 95% the way through picking up the last message, > > disconnect... *shrugs*... it may have the same effect, or TB! may > > know how to handle that event properly. > > That would be an interesting exercise. Chances are though, Windows will kill the client socket instead of TB! waiting for an event such as a server side close. In which case, we may find that doing that may not help. -- Jonathan Angliss ([EMAIL PROTECTED]) ________________________________________________ Current version is 1.61 | "Using TBUDL" information: http://www.silverstones.com/thebat/TBUDLInfo.html
