The Accidental Rubyist

invalid byte sequence in UTF-8

Thoughts on event firing

leave a comment »

Do UI’s fire events only when someone is listening, or always.

Firing an event often means creating an event object, doing some calculations of what changes were made and what positions they happened in.
Sometimes, one editing event can result in 2 events such as first a delete event and then an insert. Thus, it could be efficient to send events only when an object is listening. Currently, events are fired AFTER default behavior. This hopes to ensure that any exception or problem in a user-defined handler does not result in bypassing default behaviour.

However, i just came across this interesting line on ActionListener. It’s the opposite of what I am doing.

The root event class for all component-level input events. Input events are delivered to listeners before they are processed normally by the source where they originated. This allows listeners and component subclasses to “consume” the event so that the source will not process them in their default manner. For example, consuming mousePressed events on a Button component will prevent the Button from being activated.

Advertisements

Written by totalrecall

December 24, 2008 at 10:02 pm

Posted in rbcurse

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: