Le 4 avr. 07 à 22:21 Soir, [EMAIL PROTECTED] a écrit: > On Apr 04, 2007, at 19:59 UTC, Arnaud Nicolet wrote: > >> Le 4 avr. 07 à 21:21 Soir, [EMAIL PROTECTED] a écrit: >> >>>> Its not as my app needs to be running several processes at once. >>> >>> No, but it does need to be running two threads at once: one to do >> the >>> processing, and one to service the UI. >> >> The UserCancelled method is done for cases like that: the UI seems >> unresponsive (only a progress bar shows that the app is not hanged). >> In that case, there is only one thread needed: to do the processing. > > No... You need one to do the processing, and one to service the UI > (including animating the progress bar and doing the checks that the > UserCancelled function relies on, plus avoiding the spinning > waitcursor > and handling interaction with the Cancel or Stop button that such a > progress dialog really should have). > > But note that the one servicing the UI isn't a thread you need to > create; that's the main thread, the one that exists automatically as > soon as you launch your app. So maybe you meant that only one > explicitly-created thread is needed, and that would be correct.
Well, I was saying a mix of all that, with a slightly difference, that, in my opinion, RB handles the UserCancelled function (you can use it in a loop in the main thread and it will works correctly). _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
