WOOOOW, Thanks!!!!! El lun., 23 de mar. de 2015 a la(s) 9:29 p. m., stepharo <[email protected]> escribió:
> + 1 > Thanks Henrik!!! > > Le 23/3/15 16:17, Ben Coman a écrit : > > > > On Mon, Mar 23, 2015 at 9:06 PM, Henrik Johansen < > [email protected]> 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 > > >
