This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: How To Create A Custom Widget - Action Part Events Feed Title: Pollock Feed URL: http://www.cincomsmalltalk.com/rssBlog/pollock-rss.xml Feed Description: Pollock - the next VW GUI Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Pollock

Last time we left off with the button part of our Calendar not blowing up, but not doing anything either. We did that by adding two event handlers to Calendar. Today, we'll discuss the event handlers of an Agent, and make our button be active.

Mouse Events

In the old Wrapper world, if one was creating their own widget, one had to create and deal with a Controller. Mouse and Keyboard events in Wrapper were directed through the Controller. If you were dealing with Mouse events, then you had to also deal with a Tracker, which dealt with Mouse events while the mouse button was pressed. Also, you had to deal with rather arcane (because of history) named event handlers, like #redButtonPressedEvent:.

In Pollock, all events are routed to the Agent. Instead of a couple of dozen "colored" event methods, there is instead a handful of abstract event handlers:

• flyingOverMouseMovedEvent: - Called when the mouse is flying over (not pressed) and moved over a pane
• mouseButtonDownEvent: - Called when any mouse button is pressed
• mouseButtonUpEvent: - Called when any mouse button is released
• mouseDoubleClickedEvent: - Called when any mouse button has activated a double click
• mouseEnterMovedEvent: - Called when the mouse is flying out of (not pressed) of the bounds of a pane
• mouseExitMovedEvent: - Called when the mouse is flying into (not pressed) the bounds of a pane
• mouseWheelEvent: - Called when the mouse wheel is rolled
• trackMouseDownEvent: - Called, after a #mouseButtonDownEvent: to signal the possible start of a mouse down movement session
• trackMouseMovedEvent:startedAt: - Called when a mouse button is pressed and the mouse has moved at least 2 pixels in any direction away from it's start position.
• trackMouseUpEvent: - Called, just before a #mouseButtonUpEvent: to signal the end of a mouse down movement session

The event is passed in as a parameter to these events. If you care about which button is pressed, in the various methods, you can ask the event.

Last time we overrode #trackMouseDownEvent: and #trackMouseUpEvent:, because the superclass, ActionDisplayAgent was calling a method that our Calendar didn't support, and didn't need. Actually, our Calendar itself doesn't need to respond to ANY events! Why? Because the two sub-panes (the button and an input field) we will be using for the main Calendar will do all the event processing. You see, we don't actually have anything in the Calendar itself that the user interacts with directly.

But, it is our job to forward those events to these sub-panes.

Routing Events

Before any mouse event gets to a pane's agent and to the above mouse handling methods, it is first sent to the agent's #handlerForMouseEvent: method. This method has a simple job. Answer the pane's controller if this pane wants to handle the mouse event, or answer nil if it doesn't. Yes, the pane's controller. This is due to the event dispatching and keyboard processing code that Pollock still shares with Wrapper. This will change early next year.

For a simple pane, the #handlerForMouseEvent: will answer that controller only if the pane is enabled and visible, and the event has taken place within the pane. For compound panes, such as our Calendar, it should ask the sub-panes if they want to handle the events, and if they don't answer nil, return their answer to the #handlerForMouseEvent: message.

This is what we want to do. So, we'll write a #handlerForMouseEvent: that asks our Button if it wants to handle the event, and if so, answer it's response. In any other case, we'll answer nil, since locally we never want to handle any event:

	CalendarAgent>>handlerForMouseEvent: anEvent
		pane actionPart ifNotNil:
			[:button | 
			(button handlerForMouseEvent: anEvent) ifNotNil: [:controller | ^controller]].
		^nil

Now we test our Calendar again:

	CalendarTest new openWindowWithCalendar

We press on the button, and ta-da The button reacts, does the proper display of it being pressed and released and all that.

If you have been following closely, you see that by answering nil, we say we never want to get any event for the Calendar itself. This means we can get rid of our previously "ignore" versions of the #trackMouseDownEvent: and #trackMouseUpEvent: methods. We'll just remove them.

Now if we open our example, all is still good, and if we run our tests, all pass.

The above is published as version 1.7 in the Package named "Pollock-Calendar" on the Cincom public repository.

Next time we'll add the "display" part, which is our input field that will take up the left hand side of our Calendar widget.