--- Begin Message ---
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.johan...@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
--- End Message ---
