On 25 September 2010 09:34, Hannes Hirzel <hannes.hirzel@gmail.com> wrote:
On 9/24/10, Sean P. DeNigris <sean@clipperadams.com> wrote:
Hannes Hirzel-2 wrote:
I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass.
Which method did you like best?
Ha ha, should have been *none of these felt...*, but:
1. The on:send:to: was what I /wanted/ to do, with the downside being that it did nothing, lol.
2. The intercept of Morph>>processEvent:using: was okay, but dangerous because it's easy to lock the image when messing with this.
3 & 4. Lock&Forward and SubclassItAll were both okay, but seemed very heavy weight for listening in on one event. Â IOW I may have gone that route eventually if the behavior got complex, but didn't like being chained to it for my simple case.
Hannes Hirzel-2 wrote:
There are some notes on this issue at http://wiki.squeak.org/squeak/2477 ( Eddie Cottongim writes: I know of three main ways to handle events in Morphic.......)
Yes, he mentions #1 and #4 and adds a fifth - your own EventHandler
Hannes Hirzel-2 wrote:
Conclusion: It might be worthwile to find out more how Juan has pruned Morphic in Cuis and if it is still valuable for use, document that and put it to use in Squeak and Pharo.
Cool, I've started this as well. Â Let's keep the list posted if we come up with anything.
Sean
p.s. #1 seems to be broken in Squeak and Pharo. Â I'm going to start another thread.
Juan has in Cuis 2.6
Morph
on: eventName send: selector to: recipient
i saw such message pattern. Guess where? Announcements! :) announcer on: MyAnnouncement send: #foo to: bar
    self flag: #jmv.     "Do NOT implement EventHandler in Morphic 3 or LightWidgets.     Even more. Try to avoid all the stuff in Morphic-OldEvents"
    self eventHandler ifNil: [self eventHandler: EventHandler new].     self eventHandler on: eventName send: selector to: recipient
So the best thing as of now would be to remove this in Squeak and Pharo so that the next people who analyze this do not loose time with it and can advance more with the things which work.....
The dichotomy here is , that Morph from one side acts as an event recipient, but from another side, it acts as an events source for eventHandler. (as far as i can tell, this is an intent of introducing EventHandler). This could be managed in more gracious manner, by having a single entry point for all events, which coming to morph. Then you can write: singleEntryPointForAllEvents: anEvent self eventHandler ifNotNil: [ ^ handler handleEvent: anEvent fromMorph: self ]. self handleEvent: anEvent and get rid of repetituous code from all places, like: keyStroke: anEvent "Handle a keystroke event. The default response is to let my eventHandler, if any, handle it." self eventHandler ifNotNil: [self eventHandler keyStroke: anEvent fromMorph: self].
HJH
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.