I notice...
DebugSession >> resumeProcess
�� �� "Make sure the interrupted process is restored properly and restart the low space handler"
interruptedProcess isTerminated
ifFalse: [��
errorWasInUIProcess
ifTrue: [ UIManager default resumeUIProcess: interruptedProcess ]
ifFalse: [ interruptedProcess resume ]].
"restart low space handler"
Smalltalk installLowSpaceWatcher.
and...��
MorphicUIManager >> resumeUIProcess: aProcess
"Adopt aProcess as the project process -- probably because of proceeding from a debugger"
UIProcess := aProcess.
UIProcess resume
This doesn't seem to do anything regarding the second UI process spawned in...
MorphicUIManager >> debugProcess:context:label:fullView:notification:
With Process Browser running with auto-update on,��
running the following experiment confirms that the second spawned UI is killed.
�� ��TestCase subclass: #Example2
�� ��Example2 >> test1
�� �� �� Processor activeProcess name: 'ORIGINAL UI'.
self halt���� ��
So I'm curious, where is the code killing the second UI ?
Also curious,��when the first UI turns into a debuggger,��
why later reinstate��the first UI and kill the second UI?
If the second UI started clean and is running happily, why not leave it running��
and let first UI thread terminate normally?��
I get some strange behaviour** sometimes
, and wonder if the swap back it might be related to this.��
** Like today��#testUserPriority below��not opening a debugger at the first halt statement, or opening a pre-debug window that has a blank pane.
testUserPriority
debug := true.
Processor activeProcess priority: 38.
self halt.
highPriorityProcess := self highPriorityRunLoop.
Transcript cr.
debug ifTrue: [self halt].
3 timesRepeat: [��
Transcript crShow: 'U'.��
self wakeHighPriorityLoop.].
highPriorityProcess terminate.
cheers -ben