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
