[squeak-dev] Re: Event filters for user input events (i.e. mouse clicks etc.)

marcel.taeumel Marcel.Taeumel at hpi.de
Sat May 21 05:56:10 UTC 2016


tim Rowledge wrote
>> On 20-05-2016, at 12:33 PM, marcel.taeumel <

> Marcel.Taeumel@

> > wrote:
>> yes, I think so. You event create code is kind of awkward but I would
>> work
>> like this:
>> 
>> ...
>> [:event :target |
>>   ...
>>   event hand
>>      handleEvent: ((KeyboardEvent newFrom: event) stroke: $a);
>>      handleEvent: ((KeyboardEvent newFrom: event) stroke: $b);
>>      handleEvent: ((KeyboardEvent newFrom: event) stroke: $c);
>>      handleEvent: ((KeyboardEvent newFrom: event) stroke: $d);
>>      handleEvent: ((KeyboardEvent newFrom: event) stroke: $e).
>>   event wasIgnored: true.
>>   event].
> 
> You’d need to be *very* careful here; catching a keyboard event and then
> sending more keyboard events via the same route… 
> 
> tim
> --
> tim Rowledge; 

> tim@

> ; http://www.rowledge.org/tim
> Abdicate (v.), to give up all hope of ever having a flat stomach.

Hi Tim,

it wouldn't be the same route. Calling HandMorph >> #processEvent: means a
fresh start for processing the event argument. With all its glory. :-)
Shared state in HandMorph is an issue though:

- keyboard focus
- mouse focus
- mouse click state
- mouse over handler
- event listeners
(- event filters)
(- event stats)

However, you actually can send multiple events along the "same route" if you
mean the same target:

[:event :target |
  ...
   target "<--- do NOT start event processing over again but use same
target"
     handleEvent: ((KeyboardEvent newFrom: event) stroke: $a);
     handleEvent: ((KeyboardEvent newFrom: event) stroke: $b);
     handleEvent: ((KeyboardEvent newFrom: event) stroke: $c);
     handleEvent: ((KeyboardEvent newFrom: event) stroke: $d);
     handleEvent: ((KeyboardEvent newFrom: event) stroke: $e).
  event wasIgnored: true.
  event].

Given that there is a double-dispatch pattern in UserInputEvent >> #sentTo:
and a event type discrimination in MorphicEventDispatcher >>
#dispatchEvent:with:, we are fine, even with changing event types and not
just multiplicity in a filter.

The return value in an event filter, however, should always be a single
event. Ignored if not needed.

Best,
Marcel



--
View this message in context: http://forum.world.st/Event-filters-for-user-input-events-i-e-mouse-clicks-etc-tp4895521p4896472.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.


More information about the Squeak-dev mailing list