Morphs becoming unresponsive
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
On Mon, Mar 23, 2015 at 9:06 PM, Henrik Johansen < henrik.s.johansen@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
+ 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.johansen@veloxit.no <mailto:henrik.s.johansen@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
WOOOOW, Thanks!!!!! El lun., 23 de mar. de 2015 a la(s) 9:29 p. m., stepharo <stepharo@free.fr> 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 < henrik.s.johansen@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
Hello Henrik, I read windowEvent: anEvent .... WorldState quitSession. self removeProperty: #closeWorldDialogOpen ] but shouldn't it be windowEvent: anEvent .... WorldState quitSession. self removeProperty: #canOpenCloseDialog ] Cheers Alain
Le 23 mars 2015 à 14:06, Henrik Johansen <henrik.s.johansen@veloxit.no> a écrit :
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
participants (5)
-
Alain Plantec -
Ben Coman -
Guillermo Polito -
Henrik Johansen -
stepharo