Patterns for event handling Morphic?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Patterns for event handling Morphic?

Stephan Eggermont-3
I find it difficult to understand event handling in Morphic.
I'm using both handleListenEvent: and mouseDown: and on:send:to:
and haven't even started using announcements. What am I supposed
to be using when, and what is supposed to be replaced in Bloc?

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: Patterns for event handling Morphic?

Pharo Smalltalk Users mailing list
Hello Stephan,

For user interaction events (mouse / keyboard events..., see MorphicEvent hierarchy, HandMorph, MorphicEventHandler...):

- if you create your own morph class, then you implement mouseDown:, mouseUp: etc according to the event hierarchy.
To allow a morph to manage an event, you have also to declare that the event is of interest. This is done by redefining the handlesXXX: methods.
as an example, if you wants to redefine mouseDown:/mouseUp: you redefine handlesMouseDown: to return true.
the event is passed as argument, you can decide to return true or false according to the state of your morph and the event argument.

you have also the handleXXXX: methods. (do not mistake handleXXXX for handlesXXX). Their role is to manage incoming user interaction events.
As an example, see handleMouseDown: , it removes a possible pending balloon, it manages the focus, it starts the mouse still down management, it sends mouseDown: to the receiver...
Normally you should not have to redefine them.

- if you wants to change or add an event management dynamically or without implementing specific methods (mouseDown:), then you can use the event handler and its protocol ( on:send:to: , limited to user interaction events though)

- Additional event are implemented as Announcements such as MorphGotFocus.
These “events" are not necessarily related to the user interaction.
Announcements are suited to define your own specific events.
They allow the implementation of the Observer/Observable pattern nicely.

- HandleListenEvent: is for particular purpose, used rarely.

Bloc: only with event listeners and announcements
A morph do not directly answer to events. Instead, a morph uses an event listener chain.
Predefined events (user interactions and general purpose morph events as BlMorphGotFocus), are all  managed through event listeners.
One can also use announcements as in Morphic.
We have implemented a lot of examples.
We will explain event management in the Bloc documentation - @Sean, the doc will also include the rational ;)

hope this helps.
Cheers
Alain

> On 15 May 2015, at 22:41, Stephan Eggermont <[hidden email]> wrote:
>
> I find it difficult to understand event handling in Morphic.
> I'm using both handleListenEvent: and mouseDown: and on:send:to:
> and haven't even started using announcements. What am I supposed
> to be using when, and what is supposed to be replaced in Bloc?
>
> Stephan
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Patterns for event handling Morphic?

Stephan Eggermont-3
Thanks Alain.

On 15-05-15 23:48, Alain Plantec via Pharo-users wrote:
- HandleListenEvent: is for particular purpose, used rarely.

I wonder about the way I'm using it. When drawing a connector
between two shape morphs, I do the following:

- I have a context menu on the shape, calling #connect

MDShapeconnect
        |connector|
        connector := MDTempConnector from: self to: ActiveHand isBezier: false.
        connector openInWorld.

When creating the MDTempConnector, I start listening to the
hand's events

MDTempConnector>>to: aHand
        to := aHand.
        ActiveHand addEventListener: self.

MDTempConnector>>handleListenEvent: anEvent
        anEvent isMouse ifFalse: [ ^super handleListenEvent: anEvent].
        anEvent isMouseUp ifTrue: [ self stopListening: anEvent].
        anEvent isMouseMove ifTrue: [
                self moved.
                self highlightShapeAt: anEvent ]

And I stop listening on mouse up, possibly replacing the temporary one
by a permanent one.

MDTempConnector>>stopListening: anEvent
        ActiveHand removeEventListener: self.
        (self shapeAtPosition: anEvent) ifNotNil: [ :shape |
                from owner addMorphBack: (MDConnector from: from to: shape isBezier:
smoothCurve) ].
        over ifNotNil: [ over unhighlight ].
        self delete

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: Patterns for event handling Morphic?

Pharo Smalltalk Users mailing list
Hello Stephan,
I guess HandleListenEvent: was implemented for such a use.

Cheers
Alain



> On 18 May 2015, at 14:36, Stephan Eggermont <[hidden email]> wrote:
>
> Thanks Alain.
>
> On 15-05-15 23:48, Alain Plantec via Pharo-users wrote:
> - HandleListenEvent: is for particular purpose, used rarely.
>
> I wonder about the way I'm using it. When drawing a connector
> between two shape morphs, I do the following:
>
> - I have a context menu on the shape, calling #connect
>
> MDShapeconnect
> |connector|
> connector := MDTempConnector from: self to: ActiveHand isBezier: false.
> connector openInWorld.
>
> When creating the MDTempConnector, I start listening to the
> hand's events
>
> MDTempConnector>>to: aHand
> to := aHand.
> ActiveHand addEventListener: self.
>
> MDTempConnector>>handleListenEvent: anEvent
> anEvent isMouse ifFalse: [ ^super handleListenEvent: anEvent].
> anEvent isMouseUp ifTrue: [ self stopListening: anEvent].
> anEvent isMouseMove ifTrue: [
> self moved.
> self highlightShapeAt: anEvent ]
>
> And I stop listening on mouse up, possibly replacing the temporary one
> by a permanent one.
>
> MDTempConnector>>stopListening: anEvent
> ActiveHand removeEventListener: self.
> (self shapeAtPosition: anEvent) ifNotNil: [ :shape |
> from owner addMorphBack: (MDConnector from: from to: shape isBezier: smoothCurve) ].
> over ifNotNil: [ over unhighlight ].
> self delete
>
> Stephan
>
>