Re: [twsocket] Fwd: Re[4]: THttpCli bug -- reported earlier onanotherserver, repeating behavior again
What about setting a flag in triggerrequestdone and then checking for it with while loop just as we do now for httpready in Dorequestsync? This would eliminate the issue and let us use both sync and async together! Remember Arno the head failed message after the second get in my demo? This would solve it! Regards, SZ On 5/15/09, Francois Piette francois.pie...@skynet.be wrote: Here is the problem: Even though state = httpReady (this is what DoRequestSync checks!), there are still messages pending--onrequestdone is called later!! If this was fixed, there would be no problem with mixing sync and async methods. We just need an event which is the LASTEST message handler in EVERY/ALL cases. I know this is a design issue and not so easy but maybe you the more experienced guys can come up with a solution that is easier than I think... As I said a few days ago (but not sure it was an answer to one of your questions), to be out of any event handler and have all pending messages processed, you must use PostMessage to put a new message on the queue and do your processing from the corresponding message handler. -- francois.pie...@overbyte.be 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://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Fwd: Re[4]: THttpCli bug -- reported earlier onanotherserver, repeating behavior again
Here is the problem: Even though state = httpReady (this is what DoRequestSync checks!), there are still messages pending--onrequestdone is called later!! If this was fixed, there would be no problem with mixing sync and async methods. We just need an event which is the LASTEST message handler in EVERY/ALL cases. I know this is a design issue and not so easy but maybe you the more experienced guys can come up with a solution that is easier than I think... As I said a few days ago (but not sure it was an answer to one of your questions), to be out of any event handler and have all pending messages processed, you must use PostMessage to put a new message on the queue and do your processing from the corresponding message handler. -- francois.pie...@overbyte.be 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://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Fwd: Re[4]: THttpCli bug -- reported earlier onanotherserver, repeating behavior again
On 5/15/09, Francois Piette francois.pie...@skynet.be wrote: Here is the problem: Even though state = httpReady (this is what DoRequestSync checks!), there are still messages pending--onrequestdone is called later!! If this was fixed, there would be no problem with mixing sync and async methods. We just need an event which is the LASTEST message handler in EVERY/ALL cases. I know this is a design issue and not so easy but maybe you the more experienced guys can come up with a solution that is easier than I think... As I said a few days ago (but not sure it was an answer to one of your questions), to be out of any event handler and have all pending messages processed, you must use PostMessage to put a new message on the queue and do your processing from the corresponding message handler. Yes I recall that message. And I also remember me replying to that. Sometimes there are multiple messages that are firing each other with postmessage and there are multiple calls to onrequestdone! I know it is hard to demo so you may not accept this but this is what we experience. Thanks for your answer, SZ -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
