On Aug 16, 2009, at 4:57 17PM, Igor Stasenko wrote: > 2009/8/16 Schwab,Wilhelm K <[email protected]>: >> Sig, >> >> Two UI processes polling for input is probably what has happened. >> I should give some attention to how Dolphin prevents that. Two >> things that come to mind are raising the priority of a new UI >> thread to create a modal event loop, and (which Pharo almost >> certainly does too) starting a new UI thread when needed. >> >> My TimedEvaluator class has headless and "with progres" >> subclasses. The latter will need some porting, and perhaps the >> headless one should simply block, or at least do so in Pharo. >> >> Terminating the UI thread seems a little harsh, but that might be >> what is needed. > > Sure it is what debugger does when you closing its window - it > terminating the process you currently debugging. Nothing harsh or > wrong and nothing to worry about (usually). :) > >> Another option might be to suspend the old UI thread, start the new >> one, and then undo the damage at the end. > > There are is a little damage which is done when you doing that - > mainly the event which is currently handled is lost, but since your > intent to terminate the current process, as a result of event > handling, nothing wrong with it. As for the rest , when you start a > new UI process everything continues to work normally.
I don't know if you remember, but there was a DNU bug some months ago (probably) caused by 2 UI-processes being active for a short period of time, one nilling mouse state after the other had initiated mouse handling. At least that was the only explanation I could come up with,nobody replied whether the scenario I described was actually possible :) http://n2.nabble.com/-ANN--MouseOverHandler-refactoring-td3068941.html#a3098227 Cheers, Henry _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
