The main thread can't sleep as it is needed to process your socket events as well as the UI, but you could try causing alternative threads to sleep. You might try moving your code into a thread and setting a semaphore and releasing it when the next packet is received back from the server.
But I am leery of this as I've done things like this in the past and it becomes a bit of a nightmare to figure out what is going on at any given moment, not to mention impossible to step through in the debugger (though perhaps that has changed in the last few versions of RB I dont know) That is a lot of work, but it would let you keep your code inline. I still agree with Steve below that refactoring into multiple methods for each stage of the conversation is the "correct" way to do it. You just need a flag or an index to tell you what stage of the process you're in so that when another query comes back you know what to call with it, which can increment the counter to the next one and callback again. If you go the thread route, I'd love to hear about how it goes, please post experiences back to the list so we can make necessary feature requests to make it easier in the future. James On Apr 18, 2007, at 8:19 AM, Guillermo wrote: > Thanks Steve but Is very complex to refactor, there are a lot of calls > to the server in a lot of methods, and the method must wait for the > answer to continue: > > For example, imagine a SQL server: > > ..... > SQLSelect ----> call to the server and wait answer > for ... > SQLNext --- > calll to the server and wait answer > > next > SQLExecute --> call to the server.... > > ... and so on, Is very difficult to refactor all. > > If theren't solutions perhaps RS could implement a "sleep" for the > main thread. > > Best regards > > Guillermo > > > > 2007/4/18, Steve Garman <[EMAIL PROTECTED]>: >> In a message regarding Re: What is the correct method for synchronous >> client-server calls? dated Wed, 18 Apr 2007 10:41:19 +0200, >> Guillermo said >> that ... >> >>> I have the same problem using socket.poll, the loop consumes a >>> lot of >>> CPU cycles while waiting for the answer: >> >> Any chance of refactoring your code into two methods? >> >> Method1 does the stuff up to the poll then stops >> The socket's dataAvailable event calls Method2 >> Method2 calls Method1 again, if necessary >> >> Real life being more complex than that usually, I'm sure it will >> need more >> thought than that but just in case you hadn't considered it... >> >> >> -- >> Steve Garman >> Using REALbasic Professional on Windows XP Pro >> >> > _______________________________________________ > Unsubscribe or switch delivery mode: > <http://www.realsoftware.com/support/listmanager/> > > Search the archives: > <http://support.realsoftware.com/listarchives/lists.html> _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
