The change I made (compared to Squeak) was to check the preferences for whether halos were enabled... not sure when the commented bit happened, for reference the Squeak version (with Polymorph) was: Preferences halosEnabled ifFalse: [^nil]. self wantsHaloFromClick ifFalse:[^nil]. anEvent handler ifNil:[^self]. anEvent handler isPlayfieldLike ifTrue:[^self]. "by default exclude playfields" (anEvent shiftPressed) ifFalse:[^nil] "let outer guy have it" ifTrue:[^self] "let me have it" So, the nil check was for when the handler was being checked for playfields (guess EToys). Perhaps the check for halos enabled should be reintroduced (via Settings) unless handled elsewhere, as the comment says, useful for deployed applications. Regards, Gary ----- Original Message ----- From: "stephane ducasse" <stephane.ducasse@free.fr> To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 09, 2011 5:07 PM Subject: [Pharo-project] handlerForBlueButtonDown: anEvent Gary I was wondering if "anEvent handler ifNil:[^self]." should not be uncommented in. Now if it works like that this is better since it means that are not hanging around with a nil. Stef handlerForBlueButtonDown: anEvent "Return the (prospective) handler for a mouse down event. The handler is temporarily installed and can be used for morphs further down the hierarchy to negotiate whether the inner or the outer morph should finally handle the event. Note: Halos handle blue button events themselves so we will only be asked if there is currently no halo on top of us. Check whtehr halods are enabled (for deployment)." self wantsHaloFromClick ifFalse:[^nil]. "anEvent handler ifNil:[^self]." (anEvent shiftPressed) ifFalse:[^nil] "let outer guy have it" ifTrue:[^self] "let me have it"