Working with events

[pchapman]

In the very near future, will break event handling into a separate class.  However, in order to get a simple test (BasicTest) running, I have added code to ComponentCreator which will add an ActionListener to the JButton that is created.  The ActionListener's job is then to push a Click type ChangeEvent onto the Component's event queue (Lines 101 - 105).  So far so good.  BasicTest adds a jSeamless Event listener to listen for Click type ChangeEvent s.  So in theory, when the button is clicked, the action listener will enque the Click type ChangeEvent, which will be handled by BasicTest's event listener.

When adding the button to the Application, Add events are pushed onto the event queue.  They are processed in Component.processEvent.  Because eventHandlers is a Queue, as a handler to notify is searched for on line 1578 of Component, the listener for the Click type ChangeEvent is popped out of the queue.  So as a side-effect of attempting to find a handler for the add event, our ChangeEvent listener is taken out of the queue.  Now, when I click on the button, the Click type ChangeEvent is queued, but no listeners exist to react to it.

So, my question is, why are we using a Queue for EventHandler s?  Am I correctly queuing the Click ChangeEvent?  What am I missing here?

Coming from my Swing background, I have a predisposition to think of Listeners as things that stick around until they are unregistered.  Any light you can shed on this would be appreciated.

Thanks,

[darkfrog]

In the very near future, will break event handling into a separate class.  However, in order to get a simple test (BasicTest) running, I have added code to ComponentCreator which will add an ActionListener to the JButton that is created.  The ActionListener's job is then to push a Click type ChangeEvent onto the Component's event queue (Lines 101 - 105).  So far so good.  BasicTest adds a jSeamless Event listener to listen for Click type ChangeEvent s.  So in theory, when the button is clicked, the action listener will enque the Click type ChangeEvent, which will be handled by BasicTest's event listener.

Well, first off, it should be a standard Event, not a ChangeEvent.  ChangeEvents only occur when something is changing and a click doesn't change anything.  The fact that there is a "Event" that is instantiatable is a different concept than what you might be used to with Swing.

When adding the button to the Application, Add events are pushed onto the event queue.  They are processed in Component.processEvent.  Because eventHandlers is a Queue, as a handler to notify is searched for on line 1578 of Component, the listener for the Click type ChangeEvent is popped out of the queue.  So as a side-effect of attempting to find a handler for the add event, our ChangeEvent listener is taken out of the queue.  Now, when I click on the button, the Click type ChangeEvent is queued, but no listeners exist to react to it.

When using enhanced for-loop as you see in line 1578 of Component it does a peek, not a poll, so that does not remove the handlers, just iterates over them.

So, my question is, why are we using a Queue for EventHandler s?  Am I correctly queuing the Click ChangeEvent?  What am I missing here?

I use ConcurrentLinkedQueue when possible instead of a standard List or Collection because it is 100% thread-safe and non-blocking.  You never have to worry about synchronized blocks, ConcurrentModificationExceptions, or index out of range issues.  It is also incredibly fast for most operations.

Coming from my Swing background, I have a predisposition to think of Listeners as things that stick around until they are unregistered.  Any light you can shed on this would be appreciated.

This is true in jSeamless as well, but all listeners are wrapped around with an EventHandler that defines additional information about how to process events on an individual listener.

[pchapman]

Well, first off, it should be a standard Event, not a ChangeEvent.  ChangeEvents only occur when something is changing and a click doesn't change anything.  The fact that there is a "Event" that is instantiatable is a different concept than what you might be used to with Swing.

Change event did seem strange to me.  I took the use of ChangeEvent from EventHandler.as line 655, but I see now, on further inspection that that is for a toggle button, not for a stardard button.  Not sure what you mean about an Event being instantiable in jSeamless, but not swing.  Events are definitely instantiable in swing.  Usually you fire events with new ActionEvent, ListChangeEvent, etc.  At any rate, I'll change the code to change to a regular event.

When using enhanced for-loop as you see in line 1578 of Component it does a peek, not a poll, so that does not remove the handlers, just iterates over them.

That makes sense.  Unfortunately, my debugging does not bare that out.  I walked through the code in debug mode.  Before processing the add event, the eventHandler queue has handlers in it.  Afterwards, it does not.  It *was* late last night when I was debugging this.  Maybe I missed something.  I'll look at it some more.

I use ConcurrentLinkedQueue when possible instead of a standard List or Collection because it is 100% thread-safe and non-blocking.  You never have to worry about synchronized blocks, ConcurrentModificationExceptions, or index out of range issues.  It is also incredibly fast for most operations.

That makes sense, if all we're doing is peeking.  When I thought we where popping them off, it didn't make as much sense.

This is true in jSeamless as well, but all listeners are wrapped around with an EventHandler that defines additional information about how to process events on an individual listener.

Yeah, I saw the use of EventHandler internally.  Quite interesting.

[darkfrog]

Well, you don't instantiate an "Event", you always instantiate something like "ActionEvent" or something more explicit to your cause whereas in jSeamless Event generally has everything needed unless there is a specific type of event that needs special attributes.

That makes sense.  Unfortunately, my debugging does not bare that out.  I walked through the code in debug mode.  Before processing the add event, the eventHandler queue has handlers in it.  Afterwards, it does not.  It *was* late last night when I was debugging this.  Maybe I missed something.  I'll look at it some more.

Let me know what you find out...obviously this cannot really be the case in general though considering no even would ever reach a listener more than once in jSeamless then.

Yeah, I saw the use of EventHandler internally.  Quite interesting.

I'm very proud of the event handling system in jSeamless.  I think once you become more familiar with it you'll agree it's much more powerful than Swing in how it works.