On Aug 16, 2009, at 4:57 17PM, Igor Stasenko wrote:
2009/8/16 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
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#a3098... Cheers, Henry