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" <
[hidden email]>
To: "Pharo Development" <
[hidden email]>
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"
Locked
