> > I don't know of ANY component where it is safe to call the message pump from > > one of its event without knowing what happend. Even for a simple > > TButton.OnClick, you can get strange result if you call the message pump > > within the OnClick handler because the handler is re-entered. The problem is > > more visible with TWSocket since it is likely the event is always reentered > > because of the high rate network I/O has. > > > > > That's not entirely true. Delphi's GUI model is event-driven so I'm > willing to bet ANY call to Application.ProcessMessages will be made as a > result of handling an message or event. And I'm willing to bet most > calls to Application.ProcessMessages can be traced to ether an > TButton.OnClick event or a menu item's OnClick!
That's true, but that's just the reverse of the issue ! The issue is to have the message pump called from an event handler. What you describe is the fact that any event is somewhat called from the message pump. If you call the message pump from a simple TButton.OnClick, then the corresponding event handler may be reentered when the user clicks again on the button and bad things may happend depending on how the code is written. > And if it's such a big > issue for ICS, why isn't there a simple 5-line-of-code test that would > raise an exception if any code is re-entered? Because it would need to create a try/finally frame which would have an impact on the performance given the high rate the events may be triggered when speaking about network I/O. And it is very easy for the component user to use a flag to detect reentrancy in his own code. Anyway, the vast majority of message pump call within an event handler is a result of the developper not understanding how windows is working. Those developers add ProcessMessages call to have the screen refreshed or similar issues. That is frequently not the correct way to do it and it give strange results in many cases (for example when a user double-click on a simple button instead of simple click). > Besides, I'm asking about such behavior because of the way the THttpCli > component behaves for me. If you remember one of my earlier questions, I > had lots of problems with the component failing to connect to my HTTP > server. Using Ethereal I determined the connection is poor (lost > packets, duplicate ACK's) BUT the component still averages an too high > number of failed connections. I don't think I've had 5 consecutive > "sessions" where no connections timed-out. And I'm saying the failure > rate is too high because I never saw such a problem using my web > browser. Not once! And after the time out expires and the component > "aborts" and restarts it's Get, it usually finishes very very quickly. > So I need to ask: Is there some other obvious thing I'm missing, like a > call to Application.ProcessMessage? What else should I be looking for. Search for all ProcessMessages and ask yourself if it is really needed. Then remove it. Thinks about all indirect calls to ProcessMessages such as displaying any modal dialog box or form. -- [EMAIL PROTECTED] Author of ICS (Internet Component Suite, freeware) Author of MidWare (Multi-tier framework, freeware) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
