+ 1
Thanks Henrik!!!
Le 23/3/15 16:17, Ben Coman a écrit :
On Mon, Mar 23, 2015 at 9:06 PM, Henrik Johansen
<henrik.s.johan...@veloxit.no <mailto:henrik.s.johan...@veloxit.no>>
wrote:
I just ran into a case where all morphs became unresponsive, and
clicking anywhere only gave me the World Menu.
After some investigation, it turned out all the World submorphs
had been locked, and I could "unfreeze" them with the following
(from a new Workspace):
World submorphsDo: [ :aMorph | aMorph unlock ]
What triggered it?
Well, the image had become unresponsive, so I clicked the close
buttons a couple of times (before trying good ol' cmd-dot, which
brought up a debugger on the old UI process and let me continue).
The close dialog is modal, normally that's no problem, since the
modal morph locks all other morphs, no two can be opened at the
same time (unless you somehow let that modal morph open another),
but the close triggered by the system window's close button is
special, since it is triggered outside the control of the World.
The bug is rare in occurrence, yet easy to trigger; press the
window close button twice, cancel one of the close dialogs, all
windows that were open will remain locked and seem unresponsive.
It might be smart to rethink the whole modality concept to make
the code more robust/coherent, but for now an extra check for this
single case in PasteUpMorph >> windowEvent: (for instance, using
a morph property) should do the trick, I'll submit a slice shortly.
Cheers,
Henry
Nice find. I've been hit by this a few times and been clueless.
cheers -ben